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A. BACKGROUND 


Project Management @UlNis «cise Navy invo 
coordination of a ccmplex set of managerial and +echnical 
responsibilities. Phe compl ePXt<y §~a5 he Fesuit of such 
factcrs as «he diversified areas in which a Program 
must beccme competent and the sizé and complexity of mod¢rn 
weapons systems. The task is aggrevated and th 
Magnified by several factors including schedule l 
and resource scarcity (human, monetary, procedural ma 
ment tools, etc). Because the current institutiona 
procedures are inadsguate, a Program Manager has ins 
cient tangitle guidelines to organiz? @ project in a way 
Geeeh Will counter and miztigaz2 complexity. 

AS a consequénce, most prejects suffer incr 
Mremency which is paralleled by arise in disorg 
Meese 15 a sure result of unccntrollec comple2xi-y. 
Peemmore nctable areas of inefficiancy is in the vorocess of 
specifying the desired systéen. Sirs eve mens met ho 
pee -co cften generates nebulcus and inaccurat: 
ifications. This situation bagins a snow 
Mmercesince ambiguity as contractors, bidding on the project, 
attempt te désign a system to mee Specifications which may 
Heeebe ccmctlete or correct. Lists tors, GoOnebac:O>s are 
forced *o react +o the assum2d meaning of peor specifica- 
Mero cather than acting toward generating a clear, logical, 
emamcOrrect design. This approach to generating specifica- 
tions generally results in the contractcr's proposals not 
meeting the user's reali need. Hopefully, problems are 
disccvered early; tke later they surface, the higher the 
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Gest tO COrrect then. Ax bast, however, these undetected 
flaws cause the needless ioss of much time and noney (after 
the project is given tc a contractor) crcegardless of wnosen 
discovered. 

Reomscunmea=t2emmGcomrbliexasvy 1S ipherent but centsollable in 
el projects. WeSGuUrsen. ly ade very Jicttle in atcemeting te 
Bontrol it. The resulting disorgénizaticn leads to time and 


money losses mainly due to pocr specifications. 


Ee. PURPOSE 


This thesis presents a procsaural mathodslogy for an 
embedded weapons system's specification development and 
design dccumentétion, answering the need defined in the 
previous section. The method is abstracted from 4& cease 
study of the Harpoon Shipboard Conmand-Launch Cortrol Set 
system development initialized by Sentman and Marceney 
fRef. 1j] and refined by Olivier and Oisen ({R2f. 2). lees 
Sea intenticn +*9 show =hat by using this methodology, 
complexity will ke reduced and the following improvements to 
embedded weépons system procurement will be realized: 

i #2«S 
Ds 
Bis 


m 
ct 
ct 
(D 
t{ 


specifications generated, 


evaluation of contractor's proposals, 


oOo 
1D) 
ct 
ct 
i) 
i | 


increased efficiency within the project manager's 

@ETi Cs, 

Me better pass dcwn infcrmation available to the project 
Manager's relief, and 


Dis develcoment ccsts lowered. 


C. SCOPE OF THE METHCDOLOGY 


The methcedology discussed in this thesis is intended to 
apply to the davelopmenz: of all embedded ccmpu*ter systems 
For tactical weaponry. The possibility for a broader scope 


exists Since PieweUnass lying DEsrci oles arte widely 
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applicable. However, further generalizing of the merthod- 

ology is ne«= appropriate at this time since the cas? study 

only addressed a tactical weapons ambedded computer systen. 
Pegure~ 1. 1 shews the placement of the Software 


Engineering Methodology within the initiél weapons systan 


|--+ 


procurement phase. Fagume i.2 dscails =he general flew of 
Mene=O!) within the Scftware Engineering Methcdology. This 
figure alsc shows that while the Contractor Support Services 
feos) Contrector develops the specifications and other prod- 
ucts, ~hée Program Manager lencs guidance to and approves the 
Megal products of this process. The guidance supplied is of 
amanageriai and nct a technical nature. Since sur handling 
of the methcdslogy is concerned with the technical issues of 
how the precedures should be perftorned, the thrust of cur 
discussion will be aimed at the CSS System Dévelopmen= biock 


Seerigure 1.2. 


D. BETHCDOLOGY OVERVIEW 


It was cur determination that the system design method- 
mmegy, While g¢nerally only an abstraction from the case 
Study, must possess séveral broad traits in ordér =o meat 
the objectives stated in the Purpose, Section B. Where 
these traits were not innate in the abstracted procedures, 


the méthcdolegy was refined to ancompass them. These traits 


are introduced below. mhe Conelustons portion of this 
emesis, Chaprer 5, discusses why zach of these traits is 
necessary end how they permeate the methodclocy. 


ab 
Q 


Seiiplaecity., Simplicity ci the methodology and in «he 
understanding cf its gqeals 2nd preducts is necessary. 
Uhless a system 25 simple, it has aréeat potential to 
beceme part cf the ccmplexity problem rath 

Baee Or tts Solution. 


T2 
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peeeGeretacon Of Geod Syetem Specifications. The me*hed- 
SlogveatuccePpE cauce L£arm,. tinely=tuned, ard in-hcuse 
system specifications. Noce that the term in-hcuss 
refers =o the projact being directly supervised by 
she Frogram Ménager regardless of where the actual 
work is performed. To be most erfective, however, 


the actual work should be done in the same ceneral 


lecation as the Program Manager (1.3. the same 
Parco we Ort tcOun Dll TGang,) o5 GsOup Of Duseaings). 
This assumes that it is necessary to have physical 

3 aideeeene Dro ject 


closeness of the Program Manag 
designer in crder to achisve 
effective communication. 

Bee Genetetoer of Gocd Documentatica Preduct«s. Vie i= 2a— 
cdclogy must preduce products which ssrv2 as & prepe 
passdown to reliefs of the Frogrém Manager and his 
staff memebers. If design decisions and system spec- 
Po seathoms —sare los peeperiy documented, cerporaté 
kncwledge will surely be lost upon job turn-cver. 

meee GeEGerator 2£f Understandable Products. The method- 
elcqy §~mMuUst ELecducs products which require  1l:ttle 
formal training to understand and us Aso ec emus = 


ke couched in terminology z:aSsily absorbed by the 


average Progren Manager. 


To ensure that thes2 Droad systim traits are achieved, 
the methodology aust yield products whic 
Beeeciztic features, inter -alia undeéerstar 

L 


momen cy, efficiercy, and BEgabidi ty. 


J O 


(i) 


a h ° 
goals of all software engineering design mneéthods. 4b 
ls 


achieve zhese specific goa the software must ad 
fey structural principles. Ross, Goodenougn, and 
ca 


Ppa. 3) provide the following list 2s£ required prin 


is 





ee eecularity. Vienionelvcasiay Principle defines how to 


structure a scftware system appropriately. 


j+- 


= 
eeu= 


woe ALS unact ion. Bhewapsesadet2on Orlnciple helps 
tify essential Mee: common to superficiaily 
different entitiézs. 

Be Localization. Pnemebocelazation Psincipl> highlights 
methods for bringing r@lated things into physical 


EEGx ima © y 


pee Hiding. Pie wea dae DELP ciple Salil the 
BiitOmstence CL maki ng nonessential implementation 
information inaccessible. Ramee EO fGe= (GON S< ra. nomen 


aececemt Oo Lhicrmation. 

pee Unifosmity. The unitcrmity princiole ensures consis- 
EEncy. 

6. Completensss. The completeness principl¢e ensures 
Merwang 22 2fft Out. 

Peme COnfirmability. The confirmability principle ensures 
“hat infermation reeded to varify correctness has 
been explicitly stated. 

The methcdology must mest the goals and objectives detaiied 
@eeve and must possess «che listed traits. It must also 
Simere tc all of tke principles s£ sof 
design strategies. City © by see ligicus 4 
Titeria can the complexity of designing 

System be significantly reduced. 

There is one fundamental premis= of this methodclogy 
imperative to its success: the system software development 
jtewenOold tcp pricrity with hardware issues being deferred 
until the system specifications ars completed. In cther 
words, <zhe software decisions must drive the hardware s¢elec- 
tion. This premise has been reiterated and substantiated by 
numerous case studies performed in recent years among then 
Paley BOchm’s “scitware first machine" [Ref. 4}. In view of 


Peemcact chat the amcunt cf computer ae money spent 
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cn software is several times the amount spent on hardware, 
Base is a Legqical pricritization of project emphasis. 

The basis for the above premise is +*hat, in o 
meet the gcals of reliability, modifiability, maintai 
Mmeeity, and =o a large degree portability in software, it 
Must be procedurally developed independent cf and without 
Megard for the hardware on which it will ex¢cuts. A major 
source of frustration and inefficiency for programmers and 
Maintainers cf current tactical weapons system scoftwars is 
eae the hatdwazrée is ingrained in and arn inflaxiblse part of 
the system. Consagquently, all nodifications *9 the software 
Mic re ccuched in the limitations 9f the system nardware, 
Mmenmbeations which often require that software medificarvions 
disregard all princivles of software angineéering. if. ta¢ 
reverse process, that of allcwing the hardware to drive ths 
software, is used, these hardware deficiencies ere quickly 
realized. When this occurs, the potential for maintzinirg 
the desired goals specified above is greatly reduced 

melding Off on the hardware Specification unti the 
methodolegy is completed is not an unrsalistic propesal 
Mos iS especially trues in light of the high frequéncy of 
hardware change and upgrade which most weapons systen 
projects experience. The basic idea 
tively easy to find shelf hardwars to implement a secftware 
System while the difficulty cf achieving the design goals 
listed akeove ona specified piece of ardware is at best 
unpredictable. 

A standard argument against having the 35 
the hardware is that there are many hardware syste 
purchased (one per platform) but only one softwar: system. 
This basically implies that cost savings are more @ function 
of hardware than sofware. This argument could be valid iz 
no modifications to the softwara, wnoich deszroy its struc- 


ture, were requized. BiG IEObsDLia cy Of achieving hic 
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4 
th 
rel 
= 
ib 


ever the system's life cycle is incredibly smali. 


Seeuctuze is destroyed, the future sys*em ccsts, even in 
@esecun=2d cr constant dcllars, would invariably b2 many 
times the initial cost savings in hardware. 

aoc Oueteescating Che procedures of zhe methodology, 
she Procram Manager along with his aff must become 


Bomeliar with he current project documents and th2 specific 


purzvos2 and mission of the weapons system. Mis) fLEss. Step 
is © become intimately familiar wich the Broad 
Beecifications detailed in «the Life Cycle Management 


Milestone Zero documentation, the Justification for Méjor 
System New Start (JMSNS). These broad system requirements 
are developed obased on a projected missior h2ed bv 
Devartment of the Navy planners. In-housé efinemeant of 
these Broad Specifications due to changing needs, echnical 
advancements, and inputs from the fleet (the user group) 
meeauces a set of Initial Functional Specificaticns. Next 
Smee initial Functional Specifications are used as the input 
to =the methcdology tec design the proposed system utilizing 
mee  cancisles of scftware enginesring. Agata ra gua ey 1.1 
PRoy2d2=S a cracvhic representation of this flow. 

Three disjoint items are pertinent to the overall view 
cf che methcdology in this stage of the system development 
First, the system design is most likely being performed by a 
Memes actCct Support Services (CSS) firm. This is because the 
Procoram Maneq2@r nor his statf have che tine and in nany 
cases the ability to perform these t2sks. Siecemd pc a 


c Ss 
meets effectively part of the Program Office. Zt should 
Beeeeoe =hcucht of as a sspare ts entity buz= rath 


nical recresentative augmenting the 
+ 


This closeness ensures that r's desired 
S.stem will be generated. Geena, 2 products voroduced by 
the system are generated and updated iteratively (see Figure 
eZ) . MneseeOicanueal gpetinement Of =h2 products ensures 





gcod documentation of the perceived system. These items of 

note must be fully comprehended by the Program Managé¢r in 

coder to most effectively utilize th methedology. 

There are four output products gen2rated and refined by 
using this methodology: a detailed sez of system specifica- 
tions (the final Refined Specifications), complete Data Flow 
Diagrams and Hierarchy Charts, ‘the designed system in ADA 
System Desian Languace (SDL) with Module Descriptions, and 
Desiaqn Decision Documentation (see Appendices A-E which show 
Seese croducts for the HSCLCS design). Selleceszvely they 
cerovide allthe documentaticn required to perpetuate «he 
SemeGreat> memory of th project and to g a 
picture cf the proposed systen. Tndividually they provids 
Siem collowing functicns: 

1. Svstem Specifications. Thes? are ¢ 
Becatcisons delivered to project bid 
+he request fcr proposals. Themed Or ob Vv 
refinement of “«h2 specificaticns when entering this 
ohase of weapcenrs system development, the better ths 
chances are that bidders will develop sound systen 
corerpesals to meet the real need. 

2. Data Flow Diagrams (DFD) and Hierarchy Charts. These 
sreducts provide &@ graphic display of th> system by 
MmierySstratang the system functional operation. Using 
Onay the funetions tc be performed and the inout and 
Ooutout data nesded to perform these functions, DFD*'s 
and Functional Hierarchies ar simple to generate and 
use. 

3. Design in ADA SDL Wit Modul2 Descrip 
design provides a procedural-levei illus 
he systen. Tt documents how the required functions 
shewn in the DFD's are transposed into a hierarchy of 
Brocedures, fuctions, and tasks for data manipulation 


in order +o perform these functions. 


2 





Paves qa Deciszor Documentation. While most design 
decisions appear in cther documents (i... thes 
PicCaeions,. acGel.da, ice oles some are not feasibtl 
Siciudaple 2m Cehes oroducts. The Design Decisior 
Documentation provides a place 0 store pertinen 


facts and parameters oft the system. 


Thus far in this seczicn we have dealt with the neces- 


sary goals, Oweanes cles, and Sequirsements of the Sofvwarse 
Engineering Methodolcgy box of Figure 1.1 and xncot <the 
mechanics of the system. This is because the high-level 


view cf the methcdology must be one oF achievement of design 
objectives and not in the procedures necessary +o produce 
documents. Whether or net these objectives are met will be 
the subject of Chapter 5 


3 


Conclusions. However, to provide 
Mes OdelogyVedecasiS  Figuze 1.3 is 


ge 
a proper overview of the 
included as an iliustraétion of the iterative product fornmu- 
lation phas:. The detailed discussion of this flow and its 


subgoals is the sole subject of Chaptsar 4. 
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Figure 1.3 Detail of the CSS System Development. 
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II. BACKGROUND OF THE HARPOON CONTROL S$ 


ae I eee 


t 
iS 


ESIGN 

Recently when the missile subsystem cf the HARPCON 
Weapon System was upgraded to include two new block enhance- 
ments, <=ke existing HARPOON Shipboard Command-Launch Control 
Set (HSCICS) was rendered inadequate to sunvert the design 
features Of the new biccks cr missiles. Upon examination by 
analysts, it was decided that the existing HSCLCS software 
was not modifiable and a new design effort was necessary. 
mie, new design would need to not only cover the recent 
missile changes but aise be fexibl2 enough «=o be medi: 
Support anticipated +echnical achievements in che near 
Meeucre. This chapter will intreduce tne basic facets cf the 
HARPOON Weavon Systém and provid? background on the work 
done in two previous theses, {Ref. 1] and (Ref. 2], <ccward 
Bedesign of the HSCLCS. 


A. EXISTING HARPOON WEAPON SYSTEA 


The HARFCON Weapon System (HWS) has been deéeveloved to 
fulfill tke requirements of the Navy's anti-ship mission. 
iieendS 1s currently depisyed on surface shivs, submarines 


S@e@maircraf:. The HWS provides over the horizon anti-ship 


capability in ail weather, deyunce T2ch=. Fhe HNS is 
comprised of the missile, launcher, and command-launch 
subsystems. The ship-la unched HARPOON employs either 


Beeeata OF third party sensor daca for targeting inform- 
tion. The missile is a "launch and rorget" weapon, since no 
Ship control or information is needed after laun 

For surface ships, the HWS control and data processing 


functions are provided by the HSCLCS which has threes nodes 


é 


Semoperation: normal, casualty and training. oes) Derma t 


Mee the major functicns of the HSCLCS ar 


(D 





ipa DO Seta cton CE DOWSE tO various HWS equipment. 

2. Selection and application of missile warmup power. 

3. The abilizy te conduct various automatic and manually 
initiated tests which confirm the operability of the 
SYSTER. 

Pots e = soutien CL Ship MOtLoOn daca Erom Ship equzament. 

Bee Selection, transfer, processing and display of tar 
dared. 


PP GCO=dinatiOnm cr =ne Selection of the tactica 


~ 
= 
t+ 
(i 
fe. 
}4 
iD 


mode and type of fusinda. 
wer 6SE€lection £ the launcher cell cOMecaaineng cnc 
intended missile te be launched. 
8. Initialization of the selected missile and the super- 
vision of the exchange of data between missile and 
other HWS equipment. 


[~——mcontcol Of all Misside firing activities. 


These functions are implemented and integ 
HARPOCN Weapon Control Indicator panel ({HWC 
HARPOON Weapon Centrel Console (HWCC). 

The HWCC contains most of the HARPCON systenm-unigue 
command and launch subsystem equipment, including the Data 
Frocessor Computer (DEC), the Data Conversion Unit (DBU) and 
the HWCC lite Support equipment. Together these components 
perform data processing and conversion among various data 
types and provide interfacing with existing sénsor and 


Ship's ¢quirment. 


mies WCLP provides visual Status information *o the oper- 
feemeecauting formulation cf tha fire control problen, and 
additionally provides manual controls for the cperator. The 
existing ¥CITP is shown in appendix &. 

The DPC is a 16-bit micrecomputer peec ge SN tee Ore Gtire 
The DFC usés an ssembiy language orogram =o provide the 


follcwing: 


ees 





1. Launch envelore pa Secu Validation. 


‘tire c 
a 


ct 
wv 
ct 
i? 
O 
al 
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ram 

2. Missile command a2neration for implemen 
missile centrecl parameters including ship's attictud:, 
search pattern orders, engine starting, flight termi- 
Mation range, altimeter setting, and various s2iec- 
table flight trajectory and maneuvering nodes. 

3. Pre-iaunch testing. 

4. Pre-launch sequencing and timing. 


5. Data formatting and transfer synchronization. 


The DCU processes 411i digital and analog signal conver- 
siors as required bv installed hardware. Eye 756U also 
Peovides interfacing of targezs data inputs from <che Naval 
Tactical Data System (NTDS) Slow Interface. Ship mouioen 


parameter data is also converted in the DCU. 


B. PROBLEMS ASSOCIATED WITH EXISTING HSCLCS 


Since the existing scftware of the present HSCLCS is 
written in assemtly code and is heavily hardware d¢nvendent, 
the maintenance cost in the face of veriodic nissil® changes 
Ss cCelatively high. Also several different hardware contfig- 

m 


[etetons €xist for tte different firing plattfor 
The HSCLCS also has numérous deficiences 
Peanging a= the operator cannot fuliy control the 
of the new block missilies. Mieeaccwn the, -ODpez at 
automated assistance in engagement planning in the current 


eeocem, and there is no Gisplay of the tactical situation at 


t+ 


Me@emerr. The Current firing solution doés net have envirena- 
Mental factors included unless «ha operator considérs *hen 
Manually. On some platforms NTDS was intended to provide the 
services mentioned in most of these deficiencies but the 


Meeeon Cf the WCIE£ has inhibited =his effor+ and indeed 
4 


ct 
cs 


Many HARPOON plaz=forms donc 
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C. HARPOON WEAPON SYSTEM CONSTRAINTS 


MiemGenotrdd tts) 28 salS SSction az=e For he most var’ 
technically oriented. Managerial constra 
determined Fy competent authority at a 


upgrade cf =he HSCLCS must be abl2 to support che new block 


+4 


missiles as well as the oid ones sinc2 the old missiles wiil 
be in the fleet for scme tine. 

The implementaticn of the upgrade mus= continue to 
Beovede all previous fuctions as well as interfacing with 
NTDS. The existing launcher hardware will remain the same 
and the physical size of the HSCLCS must be the same. 

While the DPU hardware configuration cannot changs, thse 


DPC sofcware is subject to change as necessary to inplenent 


the upgraded HSCLCS. Although the current software is in 
assembly language, ties s NOt 2 LegGulrenment for the 
upgrade. System reliability of the upgrade must meet or 


Peeeced SxiSting standarads for the HSCLCS. 


D. SYSTEM DEFINITION FOR HSCLCS UPGRADE 


a) 
i 
it 
ea: 
{p 


A detailed discussion of the system definition foe: 
upgrade can b2 found in [Ref. 1]. It is Summarized below 

The heardware of the system will change significantly. 
The existing DPC will be replaced with a commercially avail- 
able CPY with additonal memory. Thea WCIP wili be modified to 
mueeeude a display which shows the current tactical situation 
and programmable softwars keys te control both the display 
and engagement pianning features which will be incorporated 
Bate the DPC software. A hook and cursor similar to thos2 
faa DS will also be provided at zths WCIP for the opesator: 
A display crocessor will be attached to the WCIP. The DCU 
hardware will remain the same however the software must be 
Changed to accommodate new inputs from NTDS and enviroa- 
mental data. 


2D 





The software upgrade of «h2 DPC which is the major part 
Beethe HSECiLCS Eocused upon by this thesis :s to ¢elininats 
the existing deficiencies mentioned in the section B of this 
chapter. Specifically, a sceftware plan must be develorced 
which prcduces adequate software that provides required 
capabilitities and is flexible enough in design <o be modi- 
fied in the future with minimum amount of blood and tears. 


E. STATE OF THE UPGRADE 


The software upgrade of ~ 


(D 
rh 
ab 


of the two previously c c 
cf the first thesis py Marone 
software plan, higuee 2.1,) and camplets che  fixrs* three 
phases. Emphasis was placed cn good sctitware en 
techniques. A systems requirements anaivsis was conducrted 
Which prcduced revised system specifications and laid the 
foundation for the preliminary design. Data flow diagrams 
and subsequent <transfcorm analysis techniques déscribed in 
{[Ref. 5] were used. ADA was choser as the system désign 
languagé in anticipation of its proclamation as the standar 
DOD SDL and because it lends itself so weil to ‘the modu- 
larity concepts necessary for modular design. 

The sé€ccend thesis by 0 nm anew Olivie=s continued the 


software development by deriving a preliminary design trom 


Vv 
the products of Maroney and Sentman. TO eomeenievlns plan, 
a final design must te completed along with detailed docu- 
mentation. iiaes tinal wdesign process is dsscuibed in the 


Moencdolccy chapter. 
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Software Plan from Reference 1. 
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ITT. SOFTWARE ENGINEERING SNAPSHOT 


The need for good softwere enginzering techniques has 


kecome increasingly evident in ths past decade with the 
exponential growth cf software develonoment and maintenance 
eos —S. Since necessity is the mother of invention, the 
number of new software engin2ering mechods and *echnidques 


has alse grown exponentially. The major contributors zo the 
e=thodolcay of this thesis, Pressman, De Marco, and Becch, 
all have derived systems for software design using their cwn 
particular styles. ince ecsuchapter we will briertly discuss 
those stvles and alse comment on some other softw 
m=thodologies. 

Beruc ur é€d design was first publicized by Yourdon and 
Contantine [{Ref. 6]. It was developed +o be used as the 
transition t90l between Structured Analysis énd accual 
implementation. Composed of various concepts, measures, 
mimes Of thumb, and analysis techniques, ‘this method with 
early davelovoment by [Te Marco is che basis for the Pressman 
d2sicn mezhcdology. 

mn { REE. 7}, De Marco describes the life cycle of 
softwar2 project from réquirements analysis to svecifica- 
pons. After an initial survey of systems requirements, a 
Gate flow analysis is conducted using data flow diagrams. 
Meemnex: Step involves creating a data dictionary ‘from the 
Memetmead=ntifisd in the data flow analysis. At *his point in 
Ce Marco's methodology, ther data Elow diagrams are <trans- 
lated into a 


Gt 


at of specifications using a subset of English 
called ructured ENG es le PEGmwmed: naqi. Sh is a 
s-ecification lanquage «hat makes us2 of a limited vocabu- 
Jarv anda limited syntax. The vocabuléry consists of 


imperative verbs, terms defined in the Data Dictionary, and 





certain reserved words for logic formatior. fae Me eolrs of 
miemcata ticw anelysis to the Structured English spect fica- 
tions is fairly algorithmic but uses several heuristics that 
will not be discussed here. De Marco also explains che 
desired traits of a design based on the specifications 
generated, but does not include a procedure for realization 
of the design. 

Pressman, [ Ref. 5], €laborates on all phases of the 
software life cycl2 énd gives several different approa 
#0 design such as data flow oriented design and data struc- 
ture oriented design. In both of these areas he carries 
software development precess through the preliminary design 
phase but dces not address specification generaticn. The 
data flow analysis cf Pressman resembles that of Ds Marco 
but his transform/transaction analysis which leads tc module 
hierarchy charts GGpcwoeuces  Signxaricantly to design 
realizaticn. 

The object oriented agesign methodology of Booch [Ref. 8] 
concerns the development of design after some sort of data 
analysis kas been ccnducted. BeecheGGes Bot indica > a 
preference as tecwhether data flow diagrams cr any cther 
Kind of analysis identifies the objects in a project as licng 
as the method is complete. Atter obi¢ects are identified and 
given attributes, this methodology develcps a system design 
by stepwise refinement of a simple pros2 description of «he 


Ssysten. This prose eévintually i Eaahs cerned .y26. “ADA 


(0 


system design languace. No gquidan POM IGCRVersacnyo2 ths 


5 


femeoni cc structured system specifications is given in <nis 
methcdolcay. 
There are several system analysis and design <cclis that 


have kescn laplemented but have not gain2d wide-spread use. 


r 


SADT (a trademark of SOFTECH, Inc) is a system ao UeerS and 


design technique developed within the Ycurdon orge ation 


Ith 
i} 


Mage lS used 485 4 tecol fer system definition, softwere 


ao 





requirements analysis, and stem design. The m¢e*hodoloay 


encompasses technical tools and a well-defined crganiza- 


tional harness through which the tools are applied. Ar. 
automated requirements anaiysis tool is SREM [Re >, 
where clements, attributes, relationships, and struc*ures 


fall parts cf the Réeguirements Statement Language (RSL)) 


fu 
4 
M 


combined tc form the details of th® requirements specifi 

i2OT . SREM was initially designed for embedded computer 
systems and requires a software support package called REVS 
Which uses computer qraphics and reports on informétion 
TLOW . Se ne ancther automated ZOC 4. S CADSAT 


hh 


(Computer-Aided Design and Specification Analys=: icon) 
which with FSL/PSA prevides an analyst with several cépabil- 
meres. These include: 
1. description of information systems, regardiess of 
aprlicaticn atréa, 
Bee Glreation Of adata base containing descriptors for 
the informaticn systen, 
ec aOaicignm. deletion, and modification of descriptors, 
and 
me 6preduction cf formatted documented and varicus 
meEOLts Oh <ne Speci £ication. 
CADSAT dceés not present a panacea but it does provide 
benefits that include documentation quality, e¢asy cross 
reference of documents, easy modification, and reduced main- 
tenance ccsts. The major disadvantage of most of these 
automated systems is that they require a considerable amounz 
Bemerainirg in erder to be used effectively. However, <=he 
concept of automated d¢sign is here to stay because the 
benefits far outweigh the disadvanczages. 
The methods described above are only ée few £othe many 
Ways that software development is being co 


° 

ezued. S=odav. 
Ow aaa? 
a 


u 
Mme design toois such as decision tabies, f1 
n 


meeo=charts, structured flow charts, a 
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abound. VersmOucSdemunen SGOpS Cz this thesis tc ciscuss 
in detail all of the methodologies, but each one is bas2d on 
the design principles outlined in this cvhesis. it €2ch 
methodoloay produces results with the desired characceris- 
tics, only through extensive experience can one judge the 
relative efficiency cf the methodologies. See) Schwere 
enginearing is still at the fledgling staqe, we can only 
hope that these methcedologies will mitigate the software 


eEisics. 
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TV. DESIGN SETHODOLOGY 


The methodology ‘fer refining embedded computer w 
systems specificaticrs, whach as the subject cf this 
chapter, is required to possess an algorithmic fcrm and 
logical design az all levels. By levels we msan the levels 
of abstraction from which the methodology can be viewed. 
Poe e€xanpie, an outsider to the project office weuld view 
the methodology es a "black box" which inputs broad specifi- 
Meesons ard fleet criveria and outouts final design specifi- 
@ee2Ons and refined design preducts (see Figure 1.1). The 
Program Manager would be heavily involved in the iterative 
refinement of the system specifications and products ani 
conseguently would see the métnodology as a_ ge n 
refinemenc tool. His "black box" would be <¢ Cc c 
Support Services (CSS System Development block of Fig 
feeeerinaliy, the CSS Contractor would view the methodol 
as an algerithm for production. Eels meadOrhacimilc  ssicw 2 
Seown in Figure 1.3. These are proper abstractions for the 
methcdolcgy; they optimally mar tha responsibilities of each 
emeere Incaividuais into sheir required lsvel cf cenceéetrn for 
detail. 

mies Chapter is concerned with introducing a nethodology 
az the CSS Contractor ievel which embraces ail of the goals 
and principles and proper trade-offs of Sottwaere Enginesring 

we 


S 
GaSe nre DOs ton Of “che 


design. This level can be vie 
abstraction hierarchy because itis the lowest level at 
which tte eéntire design is still within view. He eae oue 


belief that if this level cf the design nethodclogy is 


m 
= 
ct 
bs 
(D 
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fee s-ructuced and siagple th tire hierarchy will be 
Sis 


n 
sc. This hypothesis will be further developed in Chapte 
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The methodology, at the level specified above, was 
conceived and tuned using the following pair of guidina 


rules: i+ must have a simple, sequential form and it musz 
oF 


ut 


5 


support a data transform driven design. By data <zrans 
driven design we mean that the products of design must 
project hew a détum is interrelated to other data and how 
data is transformed as processes act upon it. The reasons 
for these ktasic requirements are th2 subject of the two 
subsequent paragraphs. The achievemant Ot. scat 
requirement is best revealed by an illustrati 
serves «his purpcse. Wot. ce JOtmectys dlagr 
is characterized by Singular inputs and Ss 
precessing block between then. This by definition is the 
simples= form of seguential flow, Saws Ne: =tr Se” “Sule 2: 


*- 


es Siied. Bagire |S. locddiz=soncily Skhews that the £2rst 
Zoe 
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Stap of tke methcdolcay or what we 


MmercatiOns into Data Flow Diagrams. DS Meu e. von. dete 
flow analysis, eEIGe ly £Cl lows De Marco's procedure 
Ohet. 71, a procedure which fully incorporates the criteria 
Bemeda.2 «crlensfcrm driven design listed in the definition 
above. It follows that the second rule is additioneily 
Eacastied. 


There are several strong reasons for reguiring a methed- 
g 


clogy with simplé, sequential fiow. For exémple, the usage 
of such a nethodolcgy iomestaal.gat-rCciward and easily 
grasped. Further, this type of flow tends t9 be highly 
Meaae tather than heuristic orisntad. But the chief reason 
we wanted simple, sequential flow was to have a structures 
Which readily supported cur methodology model. This model 


views the system as a series of functicnal mappings, e.g. 
Baca flOW analysis is a function mapping specifications into 
a hierarchy of Data Flow Diagrams (see Figure 4.1). The use 
Beene Word functicn is not intendad to imply that the 
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Figure 4.1 Meenoagology Sequentsal Flow. 
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products, i.¢ the Data Flow Diagrams, produced by the meth- 
cdology are themselves unique; the mappin Seno 
One-to-one. However, we suqgest thac each of our me*hod- 
elogy functions map their input product into 4 small set of 
Srmont products which is a realistic partition of all 
possikle cutput products. By realistic partition we mean an 
equivalence subset cf the output products which contains 
only those products having ali of the desired structure 
principles but which omits those grossly inefficient repre- 
sentaticns of the solution. The bensfit cf this terminclogy 
is it enables the reader to view the méthcdology frcm a 
familar technical vantage. Using the terminology we intro- 
duce our hypothesis that these functions retain the proper- 
ees Of the input products by transmitting them to cthe 
Seeput products. In other words the methodology functions 
mee designed to ensure that the gocd initial structure is 
@eeried fcrwarcd throughout the mecthodology. 

The m@ain reason for requiring the méetaodoslogy <zo 
Gata driven design was based or che fact that real-time 
systems (éll applications of our mathodclogy will be real- 
tine systems) are eesisst +o d2sign this way. Shceoman 
[Ref. 9] supports this hypothesis. We decided on data flow 
désign because the graphical nature of the data flew model 
supports DeMarco's [Bef. 7] belief that all products of 
analysis functions shculd be graphic. 

The procedures of the methodology represent the comvila- 
tion of related work performed by several distinguished 


pioneers in the field of software engineering. But the 


overwhelming najority cf contributions came from three indi- 


Viduals: De Marce; Pressman: ard Booch. While 2sach cf thes 


; 


Men ses the problem in the same basic light, they have ch 


» 


neéled their research efforts into differen: facets of the 
problem. The De Marco contribution consists of a method ior 


BeemertcCraang system specificaticns into a set of structured 


ps, 





products, Data Flow Diagrams, which represen=z a graphic 
solution to the specification reguirements. Pressman 


detaiis a procedure, transform/transaction analysis, for 


creating an abstracted hierarchy cf context-indepeniéent 
modules, a Function Hie2rarchy, from Data Flow Diagrams. 
Booch, claiming to have achieved object oriented design 


fRef. 8], contributes a method for developing a final dé¢sign 
given a Function Hierarchy. It will be shown later that the 
meen prcceduzce is in fact an object oriented design tech- 
megue. Figures 4.2 illustrates the specific areas of methed- 
ology ccvérage by each of the authors. Fortunately for our 
purposes, these aréas of specialization correspond to cn or 
more of the specific functions in our methodology such that 
all of them (except Specifications Rerinement which 1s our 
contribution) have beén significantly researched. Thus only 
the structural interfaces between the various ccentributors 
n¢2d to be specified before reducing che Anite Cane toa 
Series cf independent functional units (s section B). 


Mae @ecrEcrt required 5 Structurall hierface between 


Mm 


tt 


meme, ccn=ributors is frinimal. On thse 


” 


H 


urface tnis may appear 
rna 


Piez2ing inilight of the ccmplexity no lly enccuntered 
when synthesizing a cemplete product from disjoint pieces. 

But because each of the contributcrs used the same generally 
@ee-epted preduct formats at the interface points, thess 
problems were not present. No intarface is required between 
the De Marce and Pressman pcrtions or the Methodology. This 
is because Pressman uses all of the rules of De Marco to 
produce Data Flow Diagrams, ewe ceo Is <ranstorun7 
transac~ion analysis. Consequently, we can view this situ- 
ation as if De Marco and Pressman "collaborated" o 
interface. Nor is ar interface between Pressman and Booch 
required. The portion of Beoch's method ws use requires 
Smee a function hierarchy as input. Sic] sais 
Output Droduct of Pressman, HOwsecmerucal =ntelricace speci- 


fied ky tke methcdoleaqy is needed. 
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A. METHCDOLOGY CRITERIA 


ieeeeced | Sand Proanciples 


The goa for the software produced by the method- 
mmogy (understandability, reliability, efficiency, and modi- 
fiability) are generaliy accepted by software engineers as 
those crt primary importance. In ganerai, «his list ¢ncon- 
passes all of the relevant attributes necessary te ensure 
that software will realize its minimum life-cycle cost. 
These goals are defined as fcliows: 

1. Understandabiility. Understandability is that peten- 
Eta OE S@fewale CO pEOgseec= a clear and loegicai 
méaning. It is achievable in ali systems regardless 
Shee meseomplexity LE beth ta= structure and the leve 
of abstraction are appropriate for the prope 
eipeilcat 1 OD. It must be stréssed that both of these 
properties are needed. Havinjy merely a formatted 
structure yields a legibl= but compl2x product. In 
order to realize any of the other goals, undezstand- 
ability is paramount. 

Bye neliitabilaty. keliability is the ability of the soft- 
ware to functicn, under alli conditicns, as the spaci- 
fications intended. It can be thought of as freedom 


ELECT anOMOoLlZes as well as th2> absense of bletent 


mistakes. Reliability also encompasses error 
recovery, Cromoo Tye Of chs “program to continue 


precessing in thse event of non-catastrophic systen 
mau se. Achievement of total 
Peaecemaly = direicult “20 prove even in a systen 
eet ectiy cdhering to SOftwatS engineering principles. 
fe 2s impossible 0 prove! software relia 
lessér conditicns. 

Be nis acy. Pinicieucy, 2S a Structure-d=iving geal, 


u 
is wrong. Hewever, blatant inefficiency makes 2 





System impractical. The e ncy balanc2 must d¢ 
achisved by first adhering ¢ 


MancLesIwhach car of 


= 

ali other gozlis and 
«hen screening for gross inetfic 

m 


corrected by ¢ncapsulating and modifying inefficient 
medules. This is support2d py Belady and Lehman 
Preto VOjewho state toat gicbal optimization is not a 
pEaGeiGCe leObDyeeCtave, Dut taaz by localiy optimizing, 
global sub-optimization can be achieved. Thus effi- 
ereney Shewlad be Geteszod umeil a solid system struc- 
sure is established. 

tee Sodifiability. Medea bwieeye Lee broad term which 
ancompasses the ability to #asily change sofz=wars for 
enhancements or errors, for performance tuning, and 


for subsetting. The achievement of mocifiability is 


fu 


difficult because the effects of change are very har 

Ree oredicc. Thus Micdifiabiliity, more then any other 

Goat zee unavessaL@y "readuires the Strict adherence to 
Ge 


All Of Che software engineé-ing principles. 


To mest cthes¢ design goals, the principles 
mememapcer 1 (modularity, abstraction, hiding, locaiiz 
Par LOrmity, completeness, and confirmability) are the 
Primary attributes required of the methodology products. It 
seems apparent from cur readings that among <he seven prin- 
Ciples, modularity and abstraction are uniformly accepted as 
the dominant xzequirements cf all scftware. bois. 2S) Noe 
Surprising considering that these scrtware qualities, which 
logically zeduce larce problems into manageable subproblens, 
are tne most effective reducers of complexity. Tnese two 
principles are highly coupled; o9né abstracts to reduce 
complexity by modularizing and modularizes by performing a 
series of lcogical abstractions. Thus thsy should be zhceught 
of as iterative subprocesses of some higner level generic 
C 


design process. A more deh aw ed. desct int: on 


oo 





requirements and specifications to 
Seemodulerity andeabstracticn 
le 


are g 


Modularity. AS stated above 


+o address modularity es a stand-alone principis 


its simplest fcerm, however, 


ered athieved when the 
a hierarchy of 
TwWonde> fOr this 


EheuGg i, 


re¢uced <to 


ncedules. 


Spenial Soluc ICR, dice 


between two inversely prop 


decree of module complexity 
Eace Complexity. 


Abstraction. ADS tr3 ct 2en; 


CONCESPr, Lt tarea Tt 


problem has been iterativel 


refined) such «hat each of ¢ 


a sclution representation which 


of the system at this level, 


_ Gelpl rearing detail 
abstraction previde an ints 
oe 


the prebler's soluticn. 


Of the 
clogy the 


remaining princirles 


™ 


es 2 


most 
and hiding. 
principles may tend to imply that 
ens 


important on 


While 


ack 


( 


) 


ou 


end 


dence, 


( 


Racher <h 
the 


thesé principles are presented 


Geacr, is not true. 


interwoven requirements of 


sep 


modularity and abstraction +hese 


sally accepted in name or in 


fem 2c 


req 


Semon tbutors. Yet each of 
indirectly supported as met hod 
mcdule 


Pressman etresses 


4Q 


Sole Lon 


u 


be considered 


they are oz 


methodology. 


their 


independ: 


benchmark the achievement 
iven below: 


00 ~blie 
In, 


be consid- 


; is néarly imposs 


- @ 


modularity can 


MOg ene problem 1s 
atel addressable 
EGHRY h 
have a good balance 
h 


treedegres CE inter- 


= 


W) 


hiera re 


=o 


iD 


zppreach 
must 
= 


ortional measures: 


iD 


and 


EJeO78 2S NOt ean tndependent 


do 
u 


he 


- = rs — 
CepNeSS 


achieved when 
y expanded (or 
he abs*raction levels has 
captures the essense 

but specifies nec unnec- 
ls. HeVels 


liectually graspatle view 


These OG 


required of the methced- 
completeness, indepen- 
of 


second echelon 


presentation these 
ey complete the system of 
AN Mt 
arately is because unlike 


Teesou 


univer- 
by th 
tae sd \O= 
For exampls 
Wien 


SeLrce rs 20>) Oc 


= 


aefinition 
Gaither directly s 
uirements. 
nec>, 


a concept 





requires modularity, abstraction, and completeness as prere- 


gquisite principles. Thus Pressman must indirectly support 


m 


these structural ccncepts. Pikewi ==, he requires th 


simplicity of module interface in his independence concent. 


ALD 


This is actually a loose form of the hiding principle. Th 
key peint, however, is that his method builds @ structurs 
which allows hiding to be efficiently appended to the set of 
principles across «he interféece with the Booch method. Fron 
a broad scope this implies that the method embraces a nore 
Stringent set of principles at each method interface ulti- 


mately yielding a design which adheres “+c all of the néeces- 


Sary structure principles. This idea is developed in the 
next subsection. The specifications for achievement of 
these three additional concepts area given below: 

1. Ccmpleteness. Completeness, a principle stressed by 


DemMcmcOs,mmelLS a Chltacal property of the products of 
our methcdolcay. MesteeCrecicCalgty as especialiy 
appawent when perttorming the first function, date 
tlew enalysis. Ht 2S Mencdatcry =c ersure thet seca 

SYStém spSscitication is appropriately captured in at 

meadsmweone Data Ficw Diagram. imeehe £265. proecaures 
of the methodolosy voreduces &@€ compiete ser £ Data 
Flew Diagrams *hen ail subsequent stsps will have a 
good, graphical representation of the requirements by 
which to benchmark. Thus achievement of comcvleteness 
requires the assurance that each methodology function 
cea lessicirward 2li of the information from the input 
pacdicenaenco mthe Out put oEreduct. 

2. iIndevendence. Independernc3s, the chief principle 
stressec by Fressman, becomes an important concept 
when deveicping the Function Hierarchy. The degree 
of module independence can besz be qualitatively 
measured by first méasuring the levels cf cohesion 


and coupling of the modules. Cohesion is the measure 


4 4 





of nodule single-nindedness [{ Ref. 5]. The highes< 
cohesion, Woatecimicm the Goel State for maximizing 


independence, is achieved when every module has a 


Saree weet len. Coupling is tne méasure of acdule 
interconnecticn ani interdependence { Ref. 5]. The 
lowest ccupling is realiz2?d when the interitaces 
between mcdules ere simplest. LeEwvGoupLang is aise 


reguired to achieve modular independence. Thus inde- 
pendence is achieved when the design preducts have 
medules which address a specific subfunction of 
requirements and has a simple interface when viewed 
ESCH Genes Noaules. 

Bee) Hiding. Hiding, a principle develcped by Parnas and 
highly stressed in the Booch method, inplies the 


prereguisits?: achievement er completeness, modularity, 


abstraction, and independence. Pose YPeNSton ect Ene 
requirements of indepancsnce that distinguishes 
hiding as a more powerful concept is that these 


Single function modules nust have a simple interfaces, 
Peo iecrrace mS: be the only part of the module 
visible to other modules, and how «he functicn is 
accomplished within the module must be hidden 
{ Ref. 11]. Diicswiivisipiliauwy Gf medule internal 
information takes us on? step beyond what «hes 

four principles provide: design decision enc 
elon. Therefore, achievement of hiding requi 
conscious effcrt by désignérs to délay design 
decisions until «he latest vossible time and w 
decisions are made they must be encapsulated and 


concealed in the structure of the design. 


Tim Rentsch has boldly defined the requirements of 
the nebulous procedure termed object oriented design 


Pees. 12). He states that the e¢ssenss of <his cencept is an 
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adherence to the principles of abstraction, 2 rOe tae On 
hi-ding, decision encarpsulaticn, and modularity. Using his 
Meno. 0on we Can corclude two interesting facts. “rst, 
the Booch method, as Booch himself clains, is) Onvee= 
criented design. Second, our méetnodology, because of its 
strong adherence to she five major structure principles, is 
also an example of object oriented désign. As the software 
Spazz werd" oft the 1980's, ebject criented desiqn will 


undoubtedly be a must in DOD software by the 1990's. 


2. Principle Set Synthesis 


New that all cf the design concepts required in the 
methodolcgy have been formally presanted, it 15 necessary tc 
show how they are related +o the nethodology functions. 
This includes detérmiring the point at which each of these 
principles becomeS an active concapt in the design. The 
synthesis idea of this subsecticn refers to the fact that 
mmot “be individual principles are not uniformly visible 
througnout avery function of the methodology. They have a 
point at which they become necessary and are thereafter 
@eer.¢d <ftorward in the principle set. Gite seeded, t havc 
concepts cnce incorperated in the design are thereafter 
mugeiained in its structure is justified in Section C of this 
encaoO- él. 

Toe realize a principle at the optimum time in the 
Gésign, the structure must be capable of suppcrting the 
inclusion of the néw concept. A rather simple wav of 
Viewing this requires one to visualize the principle +o be 
added as needing a set of préregquisita traits. Fer example, 


she prerequisites for independence are completeness, 


al 


abpstracticn and modularity. tits ethic he -CuEren + S cm uceur > 
cf the désign contains the prerequisite traits then the 


structure will be capable of supporting the new principle. 





Becaus? «he s¢t of principles oehaves in the manne 
stated akcve, the structure requirements become increasingly 
more stringent as the design is refined. Thies 2s “eho 
he method- 
Lae “Of the 
iS 


long as 


desired effect because the ultimate objective of t 
ology is tc preduce a design which encompasses 
Sereware traits but maintains its flexibility 
possibis. 

Tke initial principle set for the methodology 
ains the concepts of abstraczion and completeness. T+ 
S$ easy to see abstraction as a nscessity because zach of 

the functions iteratively refines its products nd the 
tefinement process is based on laveis of abstraction. 
Completeness across all of the interfaces requires ne expla- 
Meron: Without all cf the parts, the design could not be 
correct. At the first interface, the DeMarco/Pressman junc- 
eon, the structure must be able to support «he addition of 
modularity. The fact that modularity is required at this 
point inthe design is no surprise considéring that the 
purpcse cf the Presszan function is to modularize. The 
second and subsequent iterations 9f the module heirarchy 
continually refine the design structure to achieve low 
module coupling and high module cohesion. When a Satisfac- 
tory trade-off between coupling and conesion is made, inde- 
pendence cr modules is achieved thus appending independencea 
Bemens set of principles. Weia2 eet So= Of Priancipiss now 
containina all the eee ieee Sie Pzessian/scocn iat sr= 
u 


S 
ciure is capabie of UperelnG f= dita. Figure 4.3 


rH 
n 
zs & Oo 


Meeustrates the synthesis of + 


3B. METHODOLOGY COMPCNENTS 
1. Data Flow Analysis 


Data flow ahalysis is the first facet of < 


h 
tion and synthesis phase of the software cequire 
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Figure 4.3 Illustration of the Principle S2t Synthesis. 
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determination process. By examining the data flow we get 
the kig picture on what the entire system receives as input 
and produces as output anc the patna that data foilows in the 
system to be designed. Data flow is our analysis start 
point because we do not want to get bogged down in specific 
areas of a system trying tc defines functions which may not 
be clear in the initial analysis. Data flow, on the cther 
hand, is usually much easier to identify than flow of 
control, which in most large scale projects is very complex. 
The primary tool we will use to examiné the data fiow will 
be the Data Flow Diagram (DFD). In this section we will 
briefly describe how to buiid a DFD summarizing the methods 
detailed in [Ref. 5] and [Ref. 7] and alsco what the DFD can 
give to the Program Manager. We will also introduce a set 


ct 2xample DFD's from the HSCLCS system that will be used a 


"A 


a case study to illustrate the methodolcgy components 


Pemoughout the chapter. 
Spoara ! lowe biagram Definition 


The data ftlow diagram is a graphical aid for 
depicting «the data flow cf the software system being 
designed. A complete understanding sf the DFD is imperative 
to the understanding cf the design methodolegy described in 
this paper. Pie mMOst ms GnueiCent Characteristics cf DFD's 
are: 

1. The diagrams are graphic. 

2. They produce natural partitions in a systen. 
3. They are multidimensional. 

4. They emphasize the flow of data. 


5. They de-emphasize the flow of control. 


Data flow diagrams are made up of four hasic 


c+ 
(n 


elemen 
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1. Data flows represented by an arrow or vector from the 
scurce of the data to the dastination. 

2. Processes represented by circles or "bubbles". 

3. Stcred information (e.g data bases or files) repre- 
sented by two horizontal parallel lines with a mean- 
ingful label. 

4. Data sources and sinks represented by boxes. 


Data flow can be broadly defined as infcermatio 


n 
flowing Eetween two frocesses or between a process arda 


i 


source or ae sink. There are several general rule 
concerning data flow. 
1. Data flow names ar2 hyphenated and capitalized. 
2. No two data flcws have the same name. 
3. Choose nanes that describe the data explicitiy cut be 
concise. 
me Daca LLow Should not represent’ a flow cf control. 
Suebaed flow 2s not considered a precess activatcr. 


Procasses invariably show some amount cf work 
performed on data. More explicitly, a process is a transfor- 
meson Of incoming data flow into outgoing data flow. Each 
process bubble should be numbered and given a uni.cgue 
d2scriptive name. 

Sources and sinks incr2as@ the readabilit of 
the DFD by showing where the net inpu~s to “he system come 
Bsom and where the net outputs go to. Sources and sinks 
differ from files and data bases in that they are considered 
momoe Cit of the context of the system. Thus, they show how 
the internal system relates to the outside world. Figure 
4.4 is the source/sink diagram for the Harpoon Svsten 


Command-Launch Centrcecl System (HSCLCS). 
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Figure 4.4 HSCLCS Source/Sink Diagran. 
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Eo DED Construction 


* 


The first point +o keep in mind during the data 


Dp 


flow analysis is not to try to learn everything at on? tin 
about the whole systen. Poin sOundoQwh Oy —CONCep tla ltzing 
the high level data flew first, deferring the development of 
the low level data flow. ESpecially avoid addressing any 
implementation details at this time and be fiexiblée enough 
mmeyour thought process to start over from scratch if road- 
klocks are encountered. Remember the data flow analysis 
process is iterative. 

The primary inpuc to the data flow analysis is 
the Broad Specifications of the system t> be designed. 
Dicect liaison with the Program Manager and prospective 
users may also provide additional information. A key point 
to remember during each phase of the methodology is that 
decisions ccenceéerning design that &€=Z@ not specifically 
addressed in the Broad Specifications must be dcocumentad at 
Mme pecint of the decision. These design decisicns will 
later be used to update the Broad Specifications. 

foestat ew ene Process, Licn rity ali n¢t input and 
Output cata flows and list them around the border of your 
working paper. This step is important because it is at this 
point that you define the context or scope of the analysis 
to be conducted. Date flow outside of the scope défined 
here will never be addressed again. 

Peeengmad tae DED is che next step of «the 
SS. Woease YOU T thy CO GO is put lines in your diegzran 


oceé 
Memeect. ng data flow and try tc connect them with circles or 
ie 


ct 


s" where 4 data transformation occurs. Yous Can: sear 


iD 


2 
Beem the inputs, outputs or in the middle whichever is <«h 
most ckvicus developrent for you. Insure flow of data goes 
from left +o right for sase of reading and avoid looping 


Maen ~O the left. If a tiLcop appears necessary, duplicates 
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the process bubble that is lcoped to in order tc k¢2p the 
data flow moving right. Do not cross lines and defer naming 
the bubkrles until later. When all of the data flows are 
connected then examine each bubble to determine if some data 
Blow occurs within a bubble ‘to achieve the bubble output. 
if SO, then break down the bubbl¢ into subprocesses and 
create lines for the new data flows discovered. ie ous 
working paper is getting flocded wich lines at this point, 
it may be time to consider a leveled DFD approach. 

Basically wit the leveled DFD the first sheer 
of working paper contains the set of lines and bubbles that 
were thought of on the first cut while subsequent sheets 
contain the internal development of bubbl¢s that were deter- 
Mined to contain internal data flow. The leveled DFD systen 
enforces top-down data analysis for large systems which in 
turn naturally induces modularity in system design déevelecp- 
ment. Figure 4.5 is an example of a first cut system DFD. 
For convention purposes the bubble which spawned the 
internal data flows will be called the parent and ¢the 
Bapbples that result are called children. For numbering 
clarificaticn a child is always given a unique number which 
is prefixed by the parents bubble or process number. As a 
correctness check, always be sure the inputs and outputs of 
the children correspend tec those of the parent and vice 
versa. It is also wise to only expand one bubble at a time 
Semeernsure continuity of thought. Data bases and files 
accessed or modified by a bubble should appear on the high 
level diagram with the parent and the appropriate lower 
Mewet d-acran with the child. I> be sure, upe 
analysis a child may develop children of its own an 
way various levels of a system would be created. Figure 
Shows how one bubble of the HSCLCS was decomposed 
new levels. Note that this particular exampl2 does not 
Baeence parent and child inputs and outputs; so further 


refinement is required to capture th2 correct data flow. 
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PaCeemOuCEEIGaIDe> 1s filled with lines and 
bubbles, ycu shculd label the data flows. Make sure wne 
nam2s of the data flows are honest, concise and descriptive. 
Be careful not to greup disparat2 items together into cne 
data flow when they have no business being ‘treated as a 
whole. If the name is not very obvious, it 1s possibie that 
you need to repartiticn or rEreak down the flow into levels. 
The naming process is designed to hélp you catch Errors in 
your data analysis so be prepared to back up and reconsider 
meeechais Ecint. 

After the data flows are appropriately labelsd, 


it is time to label and number the process bubbles. Use 
similar guidelines for naming the bubbles as you did for the 
data ficws. MA¢ecdOnd li yy,tay, ~<O GONS=tLUCtE Rhames with a 


Singular action verb and singular object. If you find ycour- 
self caught using two verbs for one bubble, it may be time 
SPeetepartiticn. 

MeancGeOne ae esatien Of the DFD process, a geod 
practice is to set it aside for awhil2 before beginning the 
refinement process. The refinement process censists of 
eXamining ¢ach bubble and data flow line to determine if 
Mmaecher decomposition is required. iutootla elon CCNt INULty 
is required on all refinements in that all incomin and 
outgoing data flows in a refinement must have appeared on 
the prévicus version. Figures 4.7 and 48 show a initial 


decomposition of a process bubble and a subsequent refine- 


ment. Th iterative process continues until the analyst 
feels that all bubpniles and data flows have been ccmpletely 


develceped or until further decomposition would not be cf any 
peactical use in his cpinion. Clearly, experience will best 
teach <wthe analyst when the bottom level is treached. 
Beemer more, final versions cf DFD*'s £rom this stage of the 
design methodology may be required +2 be modified during ths 
next phases of the methodology. 


oe 





Peomtiphe=s scr or D devetopmeat £or the HSCLCS area 


contained in Appéndix A. 
Geevoand the DED 


itemise 12. use of =the DED 1S O60 Convert this 


Beoduct into a Function Hierarchy via Bion we ran SLO ri / 
transaction analysis technique described in =e: Rexs 
secticn. The Program Manager will use the DrD's +o famil- 


maeize hinself with the basic data flow cf the design cf the 
eyecem graphically without having to traces the flow of data 
PoetOough a lengthy algorithn, Sie Ba@ad Splecifications, or 
the final design. This initial graphic understanding of the 
system to ke managed will also allow the Program Manager to 
more easily understand the final design itself ard to be 
able to quickly cenceptualize the flow of information 
refered to in the design decisions documentation. 

The data flow analysis, completed in the form of 
data flow diagrams, will lay the corner stone for the deéevel- 
opment of the deésign. This process must bé done car2fully 
“oO insure that the foundations for modularity and implicit 
informaticn hiding are established from the beginning of the 


System development process. 


ae Definitions 


Transform/transaction analysis is an algorithmic 


(" 


meennigque for develoring a Hierarchy of Functions which i 


meeemashc only on the structure of the input product, <<=h 


wa 


Tata Flow Diagrams. As the method name implies, there are 
only two high-level structural forms indigenous +o data flow 
diagrams: transform flow and transaction flow. The method 
Supposes that certain fundamental characteristics exist in 


ali scttware systems: data must be input, manipulated, and 
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output. These characteristics are broad enough in nature to 
Meme che technique widely apriicable to many types of scft- 
were development. Sp¢cificaily, the metnod is highly ccmpa- 
table with the cevelcpment of real-time Systems making it 


ideal for cur purposes. The reader desiring further discus- 


sion of the technique should ccnsult Pressman [ReEf. 5j. 

Transform flow, cur fundame2ntai system mocel for 
all data flow, envisicns the system as inputting and ocutput- 
memqg date in an “external world" form and processing (trans- 
Berming) cf infosmaticn in @n internal form. Transforn flo 
is necessary to accommodate both the user who must i 


iy 

[meer pre+ data in the external fcrm and <he computer whic 
must process data in the internal forn. Simnpiy stated,- if 
the flow of information can be viewed over time as: (1 

@tferen= flow frcem the external representation of the inputs 
Perche internal representaticn; (2) a process flow where che 
internally represented data is manipulated te produces the 
dzsired results; and (3) an efferent Tiow from the internal 


representaticn to some appropriate external display for ths 


[MeeerMac.on then transform flow is present. Bi gune 14.59 
mist crates the transform ficw of information. PEs. OFM 
flow, aS @ basic model for all software development, charzac- 


Cc 
terizes systems very simply. They lnput data, change it t 
an internal form, precess it, chang? it to a suitable outou 
Semeueturs, and cutput it. 

Tc solidify the abcve discussion, we must define 
atferent and efferent flow which is the key to the charac- 
mtazdaticn cf transfcrm flow. fFferent Slow is information 
fiow along paths which cause the gradual transformaticn of 
Saea f£rOM anh external format to an internal format. The 
transformation can be viewed as a funneling of the informa- 
Beom through external/internal interface translators +oward 
feeentccal processing peint, a transform center. BEterent 

a 


Mme 21S the flow of information outward trom the transforn 
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Figure 4.9 Transforn Flow. 


Cen=er through internal/fexternal interface translators to 
the devices which will display the results of th precessing 
to the system user. 

Teansaecetcn flow 2s characcerized by a process, 
called a transaction center, which takes an external impetus 
and causes the data flew to be directed down one of several 
Faths ¢€manating from the «ransaction center. The path taken 
is determined by the value of the input. Figur2 4.10 shows 
the generic form of a transaction flow. An easy visualiza- 
[meme OL transaction flow is tc compare it with the standard 
case statement. The case statement structur2 corresponds to 
the transaction canter, the case variable value is equiva- 


lent to the external impetus input), and the subprocess 
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Pigure 4.10 Transaction Flow. 


called when executing the case Statement corresponds t09 the 


action path taken in the Data Flow Diagram. 


es Procedures: A Cas 


Th) 


Se dy 


To present the transform/transaction analysis 


technique, a case study cf «he HSCLCS Display Engagenent 

Mcedule wiiil be used. The Data Flow Diagram pertinent te zhe 

case stucy is shown in Figure 4.8. A general rule aprlicabis 

to «his analysis is that the entire refinement process of 
© 


r 
the Data Flow Diagrams must be completed befere conmencing 


Si 





mye procedure. Otherwise, Mace pDEODe:. S =awierure ci “he 
Pumctior Hierarchy cannet 5b: assured. The precsdure 
detailed belicw provides a templates for a generic sys 
some relatively simple deveicpments, ail of these stens nav 
met be needed, €.g. seccndary flow analysis, ard can there- 
fer? be onitted. 

(i~eelOw (Gla s2e Comastiss. “The firse step or the 
procedure is to determine the ch 
data. ieees DOssi ble fOr set 
single diagram; this is the cas 


these circumstances the dominant flow patern must be det 


(y 


fened. In the case study, Slice tcamsaces:con f£i90W abouz the 
bubble lakteled "Display Engayement Controller" appears to be 
eeominan<. 

(2) Marking the Diauran. Next the Data Flow 


Diagram is annotated to shew “the various ficw bounGaarties. 
ensaction flow is dominant, we will 

Bipes fOr marking the transaction flow first and look for 
$ 


Eerent boundaries =o mark the transforn fElow 


second. TMiemeewLes, =O <ranSacrion oe begin with 
finding and isoleting the transection center. Roc heeds f:— 
HecLOn states, the transaction center is that procedural 


ur 
Baopie which ccntains multipie radially emanating date 
pachs. Laguze Ciel snOvo tne LeoOlacion cf =he transaction 


Semcer for the case study. This identification of the major 


\-~ 


fiow wili ultimately develop the upper léevei modules on the 


it 


Mec 2cn Hierarchy. To provide details for a@ good Hierarchy 
Chart, further refinement of the flow characteristics must 
re performed. Since all of the secondary flow in the case 
moey +S tlranszorm in nature, the next step is to locate the 
transform centers. They are easily found by observing the 
afferent flow into selected procedural bubbles and the effe- 
Boa. fi0w cut of others. In the case study, the secondary 


Meuron the lett side of the transaction center is detailed 
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while cn tke right side it is trivial (se2 Figure 4.12). 


The right side is trivial béecausé the flow boundaries are in 
lowest terms: a single datum afferent flow; a single 
processing bubble; anda single datum efferent flow. a heders 


ore would expect the mcdular breakdown on the input side of 
the hierarchy to be scmewhat nore detailed than that on the 
controller side. Later this will be shown to be the case. 

(3) Hierarchy cf the Dominant Flow. Once the 
Data Flow Diagram is appropriately marked, the first cut 
hierarchy for the dominant flow is generated. The fact that 
flow is the key to generating the hierarchy suppcerts the 
B@opecsi-icn that the structure built during the data flow 
analysis will be maintained. Both types or flow have 
strictly mechanical means to arriva at the first cut hier- 
archy. This is because of the way data flew diagrams are 
partitioned when marked. 

When the dominant flow is transform in 
nature tken the first-level factoring produces a «wo level 
hierarchy. The upper level is a contrcl module with a 
generic name chosen tc illustrate the global function of the 
procedure. The second level contains three generic centrol 
modules with the following functions: one coordinates the 
afferent information, the second controls the processing, 
and the third coordinates the efferent information. The 
process bubbles controlled by these thres modules are 
captured by the afferent/processing/ferferent becundaries 
Barked on the Data Flew Diagrams. 

Should the dominant flow be transaction in 
Nature, the first-level factoring produces 2 threes level 
hierarchy. The upper level performs the same function as 
its ccunterpart used in transform flow. Th2 middle level 
consists of two controllers: one for controlling mocules 
which handle the input flow to tha transaction center and 


S@emeetCcre cernrtrolling modules which handle the individual 
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Figure 4.13 Dominant Flow First Cut Hierarchy. 


paths emanating from the transaction center. The Dexwcon 
level consists of a group of modules 4ach corztesvonding to a 
Single data path out from the transaction center. Figure 
4.13 shows the first cut hierarchy for the dominant trans- 
action flow of the case study. | 


(4) Hierarchy of Sécondary Flows. fhe 22 2Se 





cuts of the secondary flows, which are handled next, are 
performed in ¢xaccly the same manner as the dominant 


The cnily difference is that the top 


ft: 


evei module, the 
Memecctier, for secendary <clow must be identif a 
Meoe@ule on the first cut dominant flow hierarchy. Be 
the secondary flows aré¢ sarked in relation to the ma 


se 
mero acCtinan: flow and cannot cross already existing £ 
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Figure 4.14 Secondary Flow Pirst Cut Hierarchy. 


boundaries, secondary flows are always encapsulated within 
either the dominant or another secondary flow. Therefore 
the tcp level centrcller of a secondary flow must map into 
some lower level module of the dominant flow's (or a 
Soen~ecOllirng secondary flow's) first cut hierarchy. Finding 
this lower level module is easy; fe 2S ane Oe cwhach 
rerforms the labeled function on the Data Flow ODOiacran. 
Meare 4.14 shows the first cut hierarchy for the secondary 
BLOW. 

(5) Second-Leve 


If 
nb 
[c+ 
Oo 
i 
}? 
{3 
1Q 
6 


Secondary factoring 
is concerned with developing the lower level modules ir the 
ierarchy. It is basically a mechanical process of locating 
modules which perform the same functions as their data flow 
diagram bubble ccunterparts. The bubbles contained within 
the flow Ecundaries created by marking thse diagrams are 
required +o be mapped into modules subservient +o the 
Memeerci ler for that particular subflow (i.e. the afferent 
processing or ¢fferent transform flows or the inpu« or 


dispazcher =ransacticn flows). 
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Tt is not mandatory <o have a one-*o-ore 
Mapping between bubbles and modules although the degree cf 
mechanicalness of the process is dependent upon this. This 
step should be performed as mechanically as practical to 
preclude less of information due to premature refinement. 
However, mapping strictly by mechanics without reqard for 


obvious Simplifications fails to decrease the complexity of 


EaGeher factoring. PEeaectrcatme GCONnsideratiors dictate <+he 
outcome of the second-level factoring. Figure 4.15 shows 
the second-level factcring for the case study. It was done 


in a mechanical fashion so that the refinement techniques 
discussed below could be more adequately shown. 

(6) Refinement Heuristics. The first cut struc- 
ture of thé hierarchy diagram has many rough edges. The 
smoothing process is not well defined; it applies a series 
cf heuristics to the Function Hierarchy to refine the svsten 


eeructure. These refinements are necessary to promote = 


(D 


=m 
software principles discussed throughout the thesis. Th 
following heuristics, offered by Prassman {Ref. 5], meet our 
needs: 

1. “Evaluate the preiiminary software design to reduce 
coupling and improve cohesion." Ifa module enccn- 
passes multiple functions, the software structure 
will suffer aloss of cohesion. EX poston . Of the 
mcdule into a set of single-function modules reqains 
the cohesion. If amodule has an unreascrably 
Sempilex antertace, Coupling will 2ancresse. Implicsion 
Seeene sUnCe 1ON 2nt> the  parenc module will simplify 
the interface. Note that implosion and explcsion 
have opposite effects on coupling and cohesion. The 
Optimal balance between coupling and cohesion is the 
goal and drives the mcdul= réfinements. 

Zo. “Attempt to tinimize structures with high fan-out; 


strive for fan-in as depth increases." An ¢xample of 
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a high fan-out structure is a tree. Pes eV ts Of 
structure does not attempt t9 abstract similar parts 
frcem modules and make them subprecedures tc 4 GuUlti- 
<ude of kigher level modules. It is therefore a 
wasteful structure. Fan-in at a low level generally 
indicates a well abstracted structure with singular 
purpose modules. 

3. “Evaluate module interfaces to reduce complexity and 
to improve? consistency." The parametézrs passed +o a 
module must be simple and consistént with the func- 
Been of the modulsc. Otherwise low cohesion and 
Gentuston on the part CE the module user will resuit. 
If acomplex interface is necessary to reasonably 
perform the désired task then all the modules in the 
immediate area should be reevaluated. 

4. "Strive for single-entry, Single exit modules, 
avoiding pathological connections." This simerly 
warns us to develop modulés which are entered at the 
top and exitted at the botton. Patholegical connéec- 
ticns are branches inte or out from the middie of a 


module. They must be religiously avoided. 


(7) Refinement 


{rd 


recess. The refinement heuris- 
tics listed above fall under the general category of module 
independence promoters. Seeking high cohesion and low 
coupling Ly the implicsion/fexplosion routine is necessary in 
varying degrees +o gain this independence. The degree of 
necessity is dependent upon the level of refinement of the 
Data Flow Diagrams. As the DFD's capture more detail, the 
humber of correct, efficient Function Hierarchies decreases 
because detail limits design options. Thus, as the set of 
DFD's approach ‘MNaximum refinement the transform/transaction 
analysis process approaches a fully mechanical algorithn. 


But kecause the level of refinement sf the Data PFPisw 
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Beagtrams is realistically (and desirably for complexity 
reduction reasons) rougn, heuristics are need2d to refine 
the Hierarchy Chart. As indicated, these heuristic prece- 
dures are not mechanical. They rely on common  sénse 
decisions by the user to transform th2 current structure to 
a form which simplifies the design. The final arbiter is 


human judgement. 


In the case study, several refinements can 
be made. Refer to Figures 4.15 and 4.16 throughout tha 
narrative. ElLEst,) tOmemcmmepS=Lec.21O0R andeconttol coupling 


all references to data in databases will be through a gén¢r- 
alized data interface, an abstract database management 
system (TBMS). Thus, the two database manager modules have 
been replaced on the final hierarchy by a generic ccntrecller 


for all calls to databases. It is beyond the scope of this 
discussion to refine the DEMS module. Next, eae VA CCEDE 
Display Engagement Command” module, widen  PeEELoCrms no 


processing, was for simplicity reasons imploded inte the 
Baccept Inputs" module. ThaGeg, the: processing cf —the 
ePrecess Inputs" module, which is done by the “Accept 
Inputs" module, and the processing of th: "Output Engagement 
Data" modulé, which consists of only 4 parameter pass, are 
not necessary to control cohesion. This type of redundancy 
is common to secondary flow analysis. Consequently, they 
were imploded into the “Input Controller" module. Next, 
Meeouse the function of the "Input Centroller™" and the 
Beece rt Inputs" nodules are identical, the structure can be 


seme lified to a single module to reduce coupling with no 


Mess Of cohesion. Note that the final name chosen for this 
second ievel module was "DSrecess MOues" ratner than. "inpus 
Semorciler’ or “Accept Inputs". This is because the name 


“Process Inputs" is the mest descriptive of these three 
candidate names for the module. MieerenaLt.Mod. ficaticn to 


meemdesign, that of abstracting similar data from the two 
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Sealing WNodules, attempts to “fan-in" the structure. cme 
shown as a dotted procedure on Figure 4.16 to show chat 


factoring is possible but not assured. 


3. Mcdular Develcpment 


Modular develcpment as a formalized procedure isa 
technique for transforming the properties of the Hierarchy 
Sagart Structures into Module Descriptions. MIME Or che 4 
required te define the modules in very general terms is 
Bentained in the structure cf the Function Hierarchy. The 
transformaticn, while seemingly subtle in nature, 1S a very 
important step in the methodology. It provides an elegant 
way Of changing the svstem specifications from their totally 
Meaphic fcrm into a short narrative forn. Paws) St Gans 2200 
is a necessary first step toward using an SDL, an ADA SCPL in 
our cas2, to further design the systen. 

The compcnents of a Medulée Description capture the 
necessary details of modules commensurate with their hkigh- 
level positicn in the design refinement process. While the 
actual format of the Module Descrind 


ae 


PeOns Mo eenot Gr1eicel, 
Pre Cccntents contained within then is. The ccmponents 
provide a ccmple+e description of tha module for this stage 
cf the design. The definitions of each cf the Medule 
Tescription parts are listed below: 

1. Module Name. This name must be the same as the cne 
on the corresponding module of the Function 
Hierarchy. 

Peeeescaule Functicn. This narrative prevides the surpsse 
of the module in broad terms. It should reveal a 
Singular purpcese in order to mest the criteria of a 
module. 

3. Supervisory Mcdules. These are the modules that call 
this nodule. It is the interface with the supervi-~ 
scry modules which is explained below. 
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4. Module Interface (Parameters). Here thé ADA 
SDI-styled parameters are listed and fare cee 
explained in a shcrt narrative. The narretive 
reveals the basic structure for “he data type of the 
parameters. {he interface is a bridge between *+his 
module and all of its supervisory modules. 

5. Suktordinate Mcduleés. These are the modules called 
within the bcdy of this module. fuets — Interface 
definitions are handled by the subordinate module's 
interface. 

6. Design Decisicn Encapsulation. This =s the singular 
decision which the nodule hides within its body. Ee 
must be a Singular decision to meet Parnas's criteria 
for a module. As the module is further develcped, 
additional Ilcwer level decisions will usuelly be 
necessary. To maintain the Parnas singularity 
reguirenent, these decisions must als> be encap- 
sualted in their own procedural structure. Thus, the 
Hierarchy Chart is a dynamic product being continu- 
ally refined as design questions arisé and decisions 


are made to accommodate then. 


Figur2 4.17 shows a recommended stvyl¢ for mcdule 
descripticns. The example is one of the modules developed 
in the case study, THREAT_ANALYSIS DISPLAY. Viewing Module 
Descripzicns as the first step of the design in the SDL and 
therefore the first products of a step-wise refinement 
Frocess for the system d¢sian, we present the descripticns 
in ADA SDL comment fcrn. Because the Module Descriptions 
contain the necessary details to fully define «the modules, 
they can ke used as the user interface in the ADA SDL 
design. 

The modules should be developed independently by 
first producing the Module Descriptions in separat¢ files 
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Figure 4.17 Saaple Module Description. 


and then writing tke SDL “code" apperded +o the Module 
Descripticns. This accomplishes two gcals. Piss cy, ve 
preserves module documentation in its most logical place and 
most desiratle forn. Second, it provides physical encapsu- 
lation of the module encouraging its independent use in seme 
cther systen. This is an initial step toward programming- 
in~the-large. 





4. ransition tc ADA Design 


The transiticn to ADA design function completes the 
system design. Using the method for segregating and docu- 
menting the Module Descriptions explained in the last 
section, the transition builds the narrative structure into 
an ADA-ccmpilable System Design Language "program", ic 
incorporates the stepwise refinement approach of detail 
abstracticn thrceughout the process. The steps involved in 
this functicn are simple to comprehend and follow for those 
moderately versed in the stepwise refinement *echnique. 

Stepwise refinement is a weii-known concept in che 
software engineering community. ewe 2S) Pec, Universally 
accepted, however, as the all-encompassing detail abstrac- 
tion mechcdclogy. Because it is very useful at this point 
in our methodology, we have endorsed it. In a nutshell, 
stepwise refinement is a decomposition procedure which 
refines a previous, higher-level view of a module. ees 
different from a similar tachnique, top-down design, because 
unlike the top-down method, stepwise refinemert is limited 
to developing only structured constructs within modules. 

Before proceding with the refinement process, the 
Data Flow Diagrams, Module Hierarchy, and Mcdule 
Lescripticns must be reviewed to identify potential modules 
for packaging and *#c look az the concurrency profile (best 
Shown by the DFD's) cf the systen. The packaging criteria 
Beast2sts of four gsnezal categories of applications for 
packages ¢€ach with multiple subcategories. The broad appli- 
cations are: named collécticns of declarations; groups of 
rélated program units; abstract data types; and abstract 
state machines. Bocch [Ref. 8] discusses these criteria in 
detail. Applying these criteria to the case study, nctice 
that tke three display modules along with the 
"PROCESS_INPUOTS"® module in Figure 4.16 would be candidates 
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for ADA vackaging. This is becaus2? by packaging these 
modules the required inputs can be hidden from the 
"DISPLAY ENGAGEMENT" module thus realizing both a grouping 
of related program units and an abstract state machine. The 


criteria fcr ADA tasks alse serve four applications areas: 


Bencurrent actions; routing messages; Managing shared 
resources; and interrupt handling. Again Booch [Ref. 8] 
explains these applications in detail. Returning <o the 


case study, these three display modules perform functions 
independently of each other as shown on Figure 4.8, the DFD, 
(i,e@. *hey do nct operate cn the same input parameters) and 
Beuseguently are candidates for concurrency control using 
the ADA task nechanisn. 

The procedures of the stepwise refinement are not 
Meee culerly rigid. AS previously stated, the main idea is 
meme deccmrose gpedules into structured constructs. The 
following steps form our methodology for completing the 
design. 

WN Ede ec EHe procedure, package, function, task, ¢tc. 
Sweat Gcad-1ONe ancluging all Sf its parameters. 

2. Write the body name cf the procedure, package, func- 
mony cask, ©&tCsun With 225 parameters, a short narra- 
erve of the basic flcw, and the appropriate end 
Statement. 

3. Replace the narrative of ths body by the high level 
COnstruc +s Of the al gorithm. 

4. Continue refining the algorithm by adding dstail 
until the desired purpose is clear. Give no more 
detail than nécessary to meet the above criteria. 

59. If during this process the need for design decisicns 
arises, defer the decision by creating a subordinate 
mcdule specifying only its iaterface. 

6. Recheck the interfaces for clarity, simplicity, and 
ccmpleteness. 
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7. Determine the design decision encapsulated in th2 
module and check that it is entered in the appro- 


priate Module Descriftion 


Figure 4.18 shows the "THREAT ANALYSIS_DISPLAY" 


I an a 
| | 
Bask THREAT ANALYSIS DISPLAY; | 
i with CATABASE MANAGEMENT SYSTEM; | 
| task bed THREAT ANALYSIS_DISPLAY is 
i myce LHR DBMS is 

| record . | 
i SHIP NAME: - these types are not { 
| SH eGiraoS : - ee One to the case | 

WEAPONS : - stud nd therefore 
| CM EQUIPMENT: — nore By ouls oped i 
i ENGAGEMENT_PLAN: \ 
end record; 

mankan < THREAT ,TYPEs 

RECORD FROM THREAT DB : THR_DBMS; 

END FILE : EOOLEAN; | 
| Ceres { 
| ND FILE := false; | 
while (not END ee Ligon 
| THREAT DB_MGR (RECORD FROM THREAT DB, END_FILE) ; 
| = develop the CRT coordinates for” this display { 
i - consistent with the known coordinates of the 
| - actual threat. put the names and coordinates 
! a ere wwUtter, MOA REAT. : 
| aed “THREAT: ANALYSIS DISPLAY; | 
a ee 


Figure 4.18 Sample Module Design in ADA SDL. 


design which completes the case study for this module. 
Stepwise refinement was used both to develop the specifica- 
Eeorms cf the task and the flow in the task body. Because 
all of tke specifications were accurate and the interface 
well-defined, this step in the methodology was easily 
performed. 


5. Specification Refinement 


= a ee eee ee [Sa EE am 4 SS ew se 


Cne of the primary goals of the methodology is to 


produce fetter specificaticns and at this point in the 
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process the existing specifications are updated by incorpo- 
rating the documented design decisions. Also 7 if certain 
decisions were deferred until now such as exception 
handling, itis the time tc include them in the specifica- 
Etons. On the first iteraticn of the methodology the input 
for the update process would be the Broad Specifications. 

We are asSufing that the Broad Sp¢cifications are 
well structured and in accerdance with current directives. 
However, at each review point cf the specifications they 
should bre screened fcr ambiguity, confusing description, 
overspecification, orthogonality, and completeness. The 
preceding crocesses in the methodology will iteéerazively 
ensure ccmpleteress, but the other undéesireabl2 attributes 
must be found editorially. We will noc belabor the reeder 
Meme) definitions of the attributes but they can be found in 
(Ref. 7}. 

A Sample set of softwere specifticatisns for the 
HSCLCS is given in Appendix F. These specificaticns were 
the product of a first iteration of the methodology for the 
system and, if approved by a Program Manager, would be the 
final refined software specifications. 

Although this section of the methodelogy aprears 
short in ccmparison to the long algorithms of the octher 
methodology components, the review of the specifications is 
extremely important and should be given an equal if nox 
greater segment of the methodology time. These specifica- 
tions will reflect the principles incorporated into the 
cther methodology preducts only if this updating process is 


done with care. 


C. METHCDOLOGY EVALUATION 


In the first section of this chapter we listed and 


d-scussed the princifles and goals that the methodolegy was 
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designed to prodtce. In this section wea will show how the 
products produced conform to the guidelines specified. 

To begin with, all of the products were created using 
concrete algorithms which were presented in a manner that a 
Program Manager could easily understand. Although the 
nrocesses did include scme heuristics, the thotgnt process 
behind the heuristics was explained thoroughiy. 

Fach of the products exhibit logical design flow at all 
levels of development. The stepwise refinement methods in 
each phase cf the methodolcgy insured that in no way dida 
cart ever get in front of a horse. From data flow diagrams 
to design +0 spécifications, system design decisions were 
deferred until the last possible moment in order +o maintain 
the maximum decree cf flexiblility and to enforce abstrac- 
=2On. This logical design coupled with «he algorithric 
methods along with emphésis on Simplicity and structure in 
each of the products gives the methodology one cf the 
primary gcals: understandability. 

mic LOUT DbDaSic principles (1.e. modularity, abstraction, 
independence, and hiding) that were enforced during the 
phases of svstem development all basically contribute to the 
modifiability and maintainability goals of the methcdoloay. 
Modularity is the first of these principies and the entire 
system development process steered the analyst toward 
abstracting common characteristics of the system into 
modules. The abstraction process kept details of design at 
the lowest possible level. By hiding design deécisicns 
Within modules, a design decision change can easily be 
incorporated intc each of the products by simply changing 
one module (ideally). Furthermore since «here exists a 
fairly simple mapping between products, 4 revision could be 
implemented easily across the board. Since independence was 
also one of the principles, Strong cohesion and weak 
coupling of modules also enhances relatively effortless 
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system scftware modification. Clearly, the software devel- 
oped is easily modified and consequently highly 
maintainable. 

The iterative nature of the methodology ansures that the 
products will be reliable. The inherent design error 
checking of the process allows the designer to be cenfident 
that the design will meet all previously required speéecifica- 
tions and that the refined specifications produced by the 
methodolecy effectively enccmpass all deSign parameters. 

To simply state that the major principles used to 
develcp the individual products insures that the desired 
characteristics are passed from vhase to phase may not be 
enough. Abstraction and completensss are natural byproducts 
of the data flow analysis methods of DeMarco, but do these 
traits prceliferate through the Pressman and Booch module and 
design development processes? Does the modularity and inde- 
pendence gained from Pressman carry over +o augment ths 
hiding principle emphasized by Boocn? The answers are 
emphatic affirmatives based on the iterative nature of the 
principle inclusion process of the methodology. 

Upon clcse examination it is easy to see that the prin- 
ciple inclusion process is additive in nature. Abstraction 
and ccmpleteness are qualities enforced in the derivation of 
the Data Flow Diagrams. Since these? characteristics are 
imbedded in the DFD's, which form the basis tor the Pressman 
y 


transaction analysis phase, they are necessarily é& charac- 


Bemeestic of that phase also. Additionally, modularity and 
independerce are emphasized on top of the abstracted, 
Semolete tcundation. Similarly, the characteristics brought 


forward from Pressman to the design development of Booch are 
added tc information hiding which is stressed in that phase. 
In tnois way w2 are guaranteed that the ultimate products 
possess tre desired traits. Iterative refinement of ths 


processes then solidifies the placement of the principles. 


eg 





\ 


An svaluation of th2 methodology would not be ccmpleéte 
without scme comment on ADA as the system Cesign language, 
however, no in-depth analysis of ADA wiil be given because 
it is outside the scope of this thesis. Besides being the 
DOD language 9f the futures, ADA, with its package and task 
mechanisms, is especially suited to enforce the information 
hading principle that is the major emphasis of <*he Booch 
phase of the methodology. Without such a language, the 


implementation of this principie would be tedious ir not 


practically impossible. In short, ADA is nez just used by 
the mezthcdology; without if the methcdolcgy would rez be 
complets. 


Even theugh we have shown that this methodology will be 
an effective tool for the Program Manager, 1+ must be 
stressed that if all of the guidelines and principles ar2 
not adhered to rigidly thoughout each phase of the process 
then the products may not reflect the qualities specified by 
the goals. To use simply medularity without hiding in mind 
cculd result in software that is net easily modifiable while 
Mee applying all of the rules of abstraction could yielda 
very inefficient design. MicmiayosedcsS<anGgutshing trait of 
this methcdology frem others such as PSL/PSA and SALT is 
that the various software engineering techniques of Booch, 
De Mazcc, Fressman, and Parras have been blended te form a 
process that generates products that can begin to cut the 
cost of software maintenance and development. T9 employ the 
process you must be well schooled in the basic principles. 

It is apparent that the goals of =he methodology have 
been achieved frem the previcus discussion, but only through 
implementation of the process can it be evaluated. The only 
readily obvious improvement upon the methodology would be to 
automate the process which is w2ll within the realm of 
Peseipility due to the algorithmic nature of the methcd- 


ology. The methodclogy was used to produce the désign 
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products for «he HSCLCS were are included in the appendices. 
For this size project the methodology appeared excellent. 
However, the isplerentors found tnat increased experience 
with the phases produced results which more closely adhered 
to the gcals and principles. Furthe: proof will be in the 
pudding. 
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¥. CONCLUSIONS 


The goal of this thesis was to davelop a system to makes 
the Program Manager's task of monitcring software develcp- 
ment of embedded wearpons systems less complex by providing 
him with comprehensible, easy to use management “ools. In 
the previcus charter we have outlined and evaluated a mecth- 
edolosy which preduces thes2 management tools, and in the 
appendices are samples of the products of the methcdology. 
The methccology was simple to implement and produced good, 
complete system software specifications that were wunder- 
standable and well documented. An explanation of the 
Program Manager's precedureé in utiiizing these software 
develcpment tools remains. 

The Program Manager will receive broad software specifi- 
@eelrons on which he will conduct a first cut evaluation 
meeo= tO givang them to a Contract Support Service (CSS) for 
generation cf refined specifications using the methodology 
See this thesis. Bieesea  SPeeicicasion rermnenen=, the 
Program Manager reviews the methodolegy preducts and feeds 
the Refined Svecifications back to the CSS if necessary for 
another iteration of the process cf refinement. This precess 
continues until optimal specifications are achieved in the 
Gpinion of the Program Manager and his staff. A close 
working relationship between CSS and Program Manager can 
accallezate the process ccnsiderably. Sp Ccaemcacions Of 
high quality is the most visibl2 product of the precess 
external tc the Program Manager's office, buc the other 
products are equally important to che management of a soft- 
ware system. 

The Data Flow Fiagrams, Module Descriptions, and dé¢sign 
with documentation are of high value. The Data Flow 
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Diagrams previde an easy-tc-read graphic representation of 
the system. The Modul2 Descriptions and the final ADA 
Tesign produced give further simple, understandable docu- 
ments that a Program Manager and 2specially his successor 
(relief) can us@ to grasp the detaiis of the software. The 
Documented Design Decisions are even more important <*c the 
pass-down evolution that so often interrupts the ccntinuity 
of a system's develcrmenc. Anew Program Manager can not 
only see the design with relative ease, but he now hasa 
histery cf how and why decisions were madé that led to the 
design. Corporate knowledge which nas historically been the 
mos= frequent casualty of the turnover process can there¢fcre 
be a survivor. The increased insight into the design of the 
proposed system also puts the Program Manager into a bstter 
position to evaluate the ultimate system contractor's design 
proposals. 

Another byproduct of better specifications is the poten- 
tial for cverall system development costs to be lowered. By 
Befining the specifications “up front", there is a reduced 
probability that the contractor will discover omitted ltems 
in the specifications that require costly change orders to 
integrate the items into the systeén. Since change orders 
allow contractors to adjust the cost of a system above the 
Original bid, reducing the number of changes minimizes 
cverall ccsts. Further in the costs lifecyclé ar¢ea is the 
capital spent on the maintenance 9f a systam once it is 
implemented. Modification of software generated by this 
methcdolcqy is relatively inexpensive as discusséd in the 
previous chapter. In most cases changes in requirenents 
would not require a complete systen redesign but only rede- 
Sign of the module affected. Maintainance costs would than 
be obviously lowered. 

The most intangible benefit gained from the methodology 


is the economy of effort gained within the Program Manager's 
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Grr. ceé. The algorithmic style cf the methodology and the 
uniformity of the products provid? guidelines for the seft- 
ware develocment. The lack cf an adequate institutionalized 
procedure for software development organization in the past 
has caused effort tc be wasted performing non-productive 
tasks. Therefore, the increased afficiency due to standard 
develcrcment procedures can be substantial. 

Software development, as mentioned before, is but a mere 
fraction cf the total effort needed to realize an embedded 
EvGtem in «he fleet. However, the escalating cost of soft- 
ware makes i+ contribute an inordinate amount *0 the total 


system costs including system maintenance. It is therefore 


¢)) 


imperative that the best software anginsering techniques be 
used to reduce the exponential growth of development and 
Malintenanc2 expense and +59 eénsutTe the Program Manager's «ask 
has minimum complexity. The metnodology promulgated by this 
thesis is a major step in developing standardized management 
procedures for software development that will reduce costs 


and crovide more maintainable weapons systems to the fleet. 
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APPENDIX A 
HSCLCS DATA FLOW DIAGRAMS 


This aopendix contains the HSCLCS Data Flow Diagrams 
from {Ref. 1}. This set of diagrams is by no means complete 
and is srovided as a sample methodology product. The same 


caveat a-plies tc each of the appendices. 
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Path Structure of Track Data Base Manager. 
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APPENDIX C 


HSCLCS MODULE DESCRIPTIONS 


appendix contain descriptions of the thirty cne 
modules of the HSCLCS from (Ref. 1]. 
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Me eR eR I ee a ee eR a oe ee 2 oe oe eK ee KK KK KK OK KK KK KK 


Module Name: CONTHOL, NUMPER QO 


Medule function: This module calls all other modules 
and determines the program flow. 


Superviscery medules: None 

Module intarfaca(parameters): 

Subordinate Modul¢s: Process Input. . 
Launcher-Missile Assignment 
Plan Engagement 
Display 


Design décisicn encapsulated: 


We Me oe ae ee ae ee eK kK ek ok a eK Ke KE OK eK KKK OK KK OK KK 


Module Name: PHOGESs LNEULT, NUMBER 1 


Module function: Sslects subordinata module tc update 
ccrrespending data base¢s. 


Supervisory modules: Control 


Mcdule interface (fara meters): 


Subordinate Modules: Ship parameter Data Base Manager 
Envircnmental Data Base Manager 
Convert Coordinates 
Threat Data base Manager 


Design decision encapsulated: 


MEK eK ae ee ae 2 oe ee KK eK OK eK eK KK OK KK KKK KK 


Module Name: SHIP PARAMETER DATA BASE MANAGER, 
NUMBER 1.1 
Module function: Update the Ship Parameter Data Base 
by e1rther manual or automated means. 
Rnpu t 


Supéerviscrvy modules: Process 
Module interface (parameters): 
Sukcrdinate Modules: None 


Desian decision encapsulated: 


107 





Me Heo ae ae ee eK afeae he ae eae he he a a eK eK oe ee eK Ke OK KOK eK OK KK 


1. Module Name: ENVIECNMENTAL DATA BASE MANAGER, NUMBER 1.2 


2. Module functicn: Update the Environmental Data Bass by 
either manual or automated méans. 


3. Suverviscry modules: Process Input 
4. Mcedule interface (parameters): 
S. Sukcrdinate Modules: None 


6. Design decision encapsulated: 


eK ae oe ee oe OK oe oe a a ae ok ee ae oe he a ae a a eK i i OK ae OK ae aK oe He ae i ee aK aK ee a KK OK 


1. Module Name: THREAT DATA BASE MANAGER, NUMBER 1.3 

z~ Module functicn: Update the Threat Data Basé¢ DY el-her 
Manual m2éns or through use of a. 
standard chip that can be psriodically 
updated and sent to all ships with 
HARPOON capability. 

3. Supervisory modules: Process Input 

4. Module inter face(parameters): 

5. Subordinate Modules: None 


6. Désign decision encapsulated: 


MEK He he He eK Ke oe eH ee ea ee a ee a ee KK KK eK KK OK KK OK 


1. Module Name: CONVERT COORDINATES, NUMBER 2 


@eenodule function:To convert all the inputs to update «rack 
data to common coordinates. The inputs 
can be manual, from own Ship's tracking 
eguipment, cr from an NTDS iink fron 


other platforms. 
3. Supervisory mcdules: Process Input 
4, Module intarface (parameters): 
5. Subordinate Mcedules: Type Track 
6. Desiqn decision encapsulated: 
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Me ae he ee He ee ee ee ee ee ee oe He ee ee ee he eK ee ee he ee ee ee ee ee eK OK aK 


2. 


Module Name: Pree TRACK, NUMBER 2. 1 


Module function:Type Track determines if *he track is to 
be ees from the data base, added zo 
the data bas2, or Sa parameters of an 
existing track are be altered. These 
actions are emer nod by selecting zhe 


appropriate subordinats modul:. 
Supervisory modules: Convert Coordinates 
Module interface (parameters 
Subordinate Modules: oe 


Design décision encapsulated: 


Me He He Hee ae He ee He ae ee ee ae ae he he he ae ee ee Ee ae He ee He ee ce Oe ee ee ee ee ee i ie ke OK 


Module Name: DELETE TRACK, NUMBER 2.1.1 

Module function: Tce eliminate tracks from the data base 
that the operator determines are no 
lenger useful. 

Supervisory modules: Type Track 

Mcdule interface(paraméters): 

Subordinate Modules: Track Data Bas2 Manager 


Désign decision encapsulated: 


FE HE HE He HE ee Se He ee Ee eK ee ee ee ee he ee OK ee ee ee ee a eK ee ee Ke eK aK 


Mcdule Name: UPDATE TRACK, NUMBER 2.1.2 


fore Sunset lon ?TOG Update the tnformation contained in 
tke Track Data Base. 


Supervisory modul¢s: Type Track 
Module interface (parameters): 


Subordinate Modules: Course and Speed 
Bearing and fange 


Design decision encapsulated: 
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So RR iotok kd OR CK KKK RK RK KKK RK RK RK RK 


1, Module Name: COURSE AND SPEEC UPDATE, NUMBER 2.1.2.1 


meemodule function: Ic update the course and, speed 
30n On gach track contained i 
Toy Data Base. 


Iinfor- 
n the 
3. Supervisory modules: Update Track 
4. Medule interface (farameters): 
5. Subordinate Modules: Track Data Basé Manager 


6. Design déecisicn encapsulated: 


Mea Hee He ee ee eee eae ee ee ee He 2 oe ee ee ee a ee He ee ee a eR OK 


1. Module Name: BEARING,RANGE AND POSITION UPDATE, 
NUMEER 2.1.2.2 
feeecaule furcticn: Ic update the bearing/rangs and position 
(Iattie ude /Longizaday Pisa taw lew OF 
€ach track in the Track Data Base. 


3. Supéerviscry modules: Update Track 
4G. Module interface (parameters): 
5. Subordinate Mcdules; Track Data Bas2 Manager 


6. Design decision encapsulate 


ME ee he ee He ee eee oe ee Re i ee eRe ee eee ee eK ee ek ek eK KK KKK KK 


1. Moduie Names ADD TRACK, NUMEER 2.1.3 


2. Module function: Te allow new tracks to be put into the 
Track Data Basa. 


3. Supervisory modules: Type Track 
4, Module interface (parameters): 
5. Subordinate Modules: Track Data Bases Manageér 


6. Design d¢ecisicn encapsulated: 
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We HK He a Ke Ca ce eae ee aK ee KC ie 2 ee ee oe ie ae Oe Ke ee IC ee ee eK ee RK OK OK KOK 


1. 
D. 


4. 
Je 
6. 


Module Name: LAUNCHER AND MISSILE ASSIGNMENT, 3.1 


Module function: Allow the operator to bypass «he 


SiGe dewene pladring automatic 
selection of missile cell 
and Simply select and launch the 
missile manually. 
Supervisory modules: Control 
Modul2 interface (parameters): 
Subcrdinate Modules: Launcher and Missile Status 


Design decision encapsulated: 


Me HEE He ee He eR ee ea ae ie RK oe ie oe ae ee eK ae eK oe Ne Ee KK ei OK a oe EK ROK AE OK KK Kk 


4. 
D 
6). 


Module Nam2: LAUNCHER AND MISSILE STATUS, NUMBER 3.1.2 

megule LUnCtion: Te provide current information cn whet 
tAzUnGnerS A(perc - ees! are ready 
t¢ fire and which and what types 
missiles are ready to fire. 


Superviscry mcdules: Launcher Missile Assignment 
Engagement Daca 


Module interface (parameters): 
Subcrdinate Modules: None 


Design déecisicn encapsulated: 


WK MK ee ee ae ee a oe ie ee ee ae he ee ee i ie oe oe 2 ee 3 oe ok oe ok eo ke ee ee Kk OK Kk 


Module Name: PLAN ENGAGEMENT, NUMBER 3.2 


Module function: To determine the optimum engagment plan 
fcr a given targ?t. 


Supervisory modules: Control 

Module interface({parameters): 

Subordinate Mcdules: Plan Engagement Data Base Manager 
Engagement Data = One le 
BROAD sy Of AEGULSiTiLOn 


Design decision encapsulated: 





Wee HH ee eK ee He eK KK OK KK KK 


NK ENGAGEMENT DATA BASE MANAGER, 
Bie. Seizes | 


2. Module function: To undate the Engagement Plan Data Base. 


1. Module Nene: is 


3. Supervisory mcdules: Plan Engagement 
4. Module interface (parameters): 
5. Sukordinate Modules: None 


6. Design decision encapsulated: 


Fe AE eK oe Ke He Ee ee ee I eK ee eK Oe ae ee Re KK KKK eK KK KK KK 


1. Module Name: ENGAGEMENT DATA, NUMBER 3.2.2 


2. Module function: This module suppliz2s the data 
by the Plan Engagemen= module 
cenerate the engagement plan. 


atw 

OM 
iD 
Qs 
(D 
ba 


3. Supervisory modules: Plan Engagement 
4. Module interface (parameters): 


5S. Subordinate Modules: Launcher and Missile Status 
Mireact Data 


6. Design decision encapsulated: 


EAE HE AK Ae RR Re RE ee RK OK OK eK OK OK KK 


1. Module Name: THREAT DATA, NUMBER 3.2.2.1 
n 


elcepEoved-mene Intotmatton contained in 
the the module to the Engagement Data 
mcdule when requested. 


meenrodcule functic 


3. Superviscry modules: Engagement Data 
4. Mcdul¢ interface (farameters): 
5. Subordinate Modules: None 


6. Design décision encapsulated: 





We He He He eK he ee eae he he ee eR EE 2 ee KK EK KK KK 


t. Module Nam2=: PROEABILITY OF ACQUISITION, NUMBER 3.2.3 

2. Module function: Ic determine what the probability is 
that 2i a m2sstic 18 fired a= a given 
target that the missile can acquire 
and hit thse target 

3. Supervisory modules: Plan Engagement 

YW, Module interface (parameters): 

5. Sukordinate Modules: Uncertainty Ellips¢ 


6. Design decision encapsulated: 


AK He KK He oe EE eR ee a AK RK eA KX aK FE XO KK KOK 


feeerodule Name: ONCEATAINTY ELLIPSE, NUMBER 3.2.3.1 

2. Module functicn: Tc_compute the parameters for an 
Ellipse of uncertainty around a 
CeieaceS pPOSLELOn. 

BeepoWpervisory mcdules: Prokability of Acquisition 

4. Module interface (farameters): 

5. Subordinate Modules: Track Data Base Manager 


6. Design decision encapsulated: 


WEE HE KK Ce ie eK He a ie eK oe Ke HC oe ie ee OK ok ee ie oe OK ok ek ee oe ee i ee a ok ok oe eK KK 


1. Module Name: DISEFLAY, NUMBER 4 


feerrodule function: To call subordinate modules 


‘ Ss necessary 
tc generate required displays. 


a 
S 
3. Superviscry modules: Contrcl 
4. Module interface (rfarameters): 
5. Subordinate Modules: Menu eee! ee . 
Launcher and Missile Status Display 
Envirenmental Display 
Engagement Display 
Ship Parameter Display 
Diao ees Ula y 


6. Desiaon decision encapsulated: 


as 





eK eK eK Ke ee He OK eK KK RK KK KK OK KKK KK 


1. Module Nem2: MENU DISPLAY, NUMBER 4.1 

Z Module functicn: Te access the Menu/State Data Bass and 
displey «he required menu when called 
and keep track of the state of the 
program. 

3. Supervisory mcdules: Display 

4. Module interface (parameters): 

5. Subordinate Modules: Menu/States Data Base Manager 


6. Design d¢écision encapsulated: 


Me ee eK He He ee ee ee eM a KK eK eK KE eK KR RE KK OK OE KK OK 


1. Module Name: LAUNCHER ANT MISSILE STATUS DISPLAY, 
NUMBER 4.2 


Peedodule function: Te access the Launcher and Missile 
Status Data Base and provide a display 
Cie tome ntonmat ton CcOncained in that 
cata bas¢. 

3. Supervisory medules; Display 

4. Module interface (parameters): 

5. Subordinate Modules: Launcher Missile Data Base Manager 


6. Design décisicn encapsulated: 


FE HFK eK eK KK eK ee ee eae eK ee ee Ae ee ee ee OK Ke KK KK KKK KK 


1. Moduie Name: ENVIRONMENTAL DISPLAY, NUMBER 4.3 


Peeenodule function: ae access the Bhv 7DoOnment el a 
provide a display of the 
Eee in that data base. 


ray 
O 


S. Supervisory mcdules: Display 
4. Module interface (parameters): 
5. Subordinate Modules: Environmental Data Base Manager 
6. Design decision encapsulated: 





i ote ee ee a ee ee KK KK KK KKK KK KK OK KK KR 


1. Module Name: ENGAGEMENT DISPLAY, NUMBER 4.4 


mee Module function: To oe display the flig 
Ge Masoies that are to be flew 
a See target. fhreat data on “h 
will also be fates eo: The ¢ng 
plan will have the ove tay = 
Superimposed over the genera 
display. 


Dit) pw 
ct 
re 


THQ tact 
cro os 


wo Ss word 


Qow ct » 


3. Supervisecry medules: Display 

4G, Module interface (parameters) ; 

5. Subordinate Modules: Threat Display 
Automatic Engagement 
Manual Engagenenz 


6. Design decision encapsulated: 


Set ORK KR KK ok Kk KKK KKK RK KAR RAK KK KAKKAKKAAEK A RKEKKKAK 


1. Module Names THREAT DISPLAY, NUMBER 4.4.1 

2. Module function: To access the Threat Data Base and 
ErOwmacecdeatspiay Of ~EhS informa tior 
cont ain ed that data base. 

3. Supervisory mcdules: Display 

G. Module interface (parameters): 

5. Sukcrdinate Modules: Threat Data Base Manager 


6. Design decision ancapsulated: 


ME IK RE A a eK RK eK RK KK KK KK KK RK KKK RK KKK KKK 


1. Module Name: AUTCMATIC ENGAGEMENT 

Sere dule funccicon: Te grephically d 
plan that was _gé 
Engagement modal 
Engagement Plan 

3. Superviscry modules: Engagement Di 

4. Modul interface (parameters): 

>. Subordinate Modules: Engagement Plan Data Base Manager 


6. Design decision encapsulat=d: 


late 





Wee He ee ee ee ee ee ee EK A EC KK KOK 


1. Module Name: GRAEHICS DISPLAY, NUMBER 4.4.2.1 
ae figguie Mimce2on- — LOmDEavide the. Operator With the capa- 
ty 
; tc manually input an engagement pdlan fer 
StteGkKi ng @ Given target. 


3. Supervisory mcdules: Automatic Engagement Display 
Mandal Engagemenc Display 


4. Module inter face(fara meters): 
5. Subcordinete Modules: None 


6. Design d¢cision 2ncapsulated: 


WK HE ee Me oe eh ee eK ee eae eK ee He Ke RC Ee ee KK KK KK OK 


1. Module Name: MANUAL ENGAGEMENT DISPLAY, NUMBER 4.4&. 3 

2. Module function: To provide zhe Operator with the 
Capac a2 ay 0 manually input an 
engagemen pian for attacking a 
given targst. 

3. Supervisory modules: Engagement Display 

4. Module interface (parameters): 

5. Subordinate Modules: Graphics Display 


6. Design décisicn encapsulated: 


SKK He He He he He He HK He ee ee ee He eK eK KK KK kK eK HK 


1. Module Name2: SHIP PARAMETER DISPLAY, NUMBER 4.5 

2. Module functicn: To access the Ship Parameter Data Base 
and provide a display of the informati 
contained in that data base. 

3. Superviscry medules: Display 

GW. Mcedule interface (parameters): 

5. Subordinate Modules: Ship Parameter Data Base Manager 

6. Design decision encapsulated: 
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He AK ee he ee eK eK KK KK KKK KK KK KK 


1. Module Name: TRACK DISPLAY, NUMBER 4.6 


2. Module function: To access the Track Data Base and 
rovide a ccntinuous display of a 
eee being maintained in that d 
ase. 


ae 
area 


3. Supervisory modules: Display 
4, Mcdule interface (parameters): 
5. Subordinate Mcdules: Track Data Base Manager 


6. Design decision encapsulated: 





irxy 
3 
(fu 


HSCLCS ADA DESIGH 


ADA HSCLCS design from [{Ref. 2}. 


Update is 
Task Launcher-Missils_Status is 
entry Update ({Launcher-Missile secus: 
in Status Type) 
d Launcher-Missile Status 
ask Ship-Parameter is 
entry Update (Ship-Parameter: an 
Ship-Parameter- Typs) 
End Ship-Paerameter 
Task Ervironment is 
entry Update (Envircnment: in Environment-Type) 
nd Environment 
Task Threat is 
entry Update (Threat: in Thre2at-Typ?2) 
End Threat 
Task Update-Track is 
entry Add (Track: in Track-Type) 
entry Delete (Track: in Track-Type) 
entry Modify (Track: in Track-Type) 


Update Track 


ra} 
to srs 
pu fo 
Ww Qu 
ch 
m 
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Package Auto-Engagement is 
Procedure A-Engagement (Launcher-Missile-Scatus: in 
Scacus aay ps, Tied: : in Threat Type, 
Engagement -Plan: out Engagement-Plan-Type) ; 
Procedure Prob-cf-Acquisition (Engagement-Plan: in out 
Frocedure Uncertainty-Ellipse (Engagement-Plan: in cut 
Engagement -Plan_typé) ; 
End Auto-Engagement 


—_——_ ae ae 


Erocéedure M-Engagement (Launcher-Missiis Status: in 
> Satus-L1ype, Engagement-Plan: out 


Engagement -Pian-Typs) ; 
End Manual-Engagement 





isplay is 

Menu-Display is 

ertry Access (Menu: out Menu-Typs) 
Menu-Display 


Launcher-Missile-Status is 


encry Access (Latmene=r -MySsside—-Status: out 
status-Type) 

Launcher-Missile-Status 

Ervironment is 

entry Access (Envirenment: out Environment~Ty ps) 

Environment 

Ship~Parameter is 

entry Access (Ship-Parametéer: a) es 
Ship-Paramet er- Type) 

Ship-Parameter 

Teack 2s 

entry Access (Track: cut Irack-Type) 

foe 

Threat is 

eneey saceeCce ((t1red.s Ouc Threac-Type) 

Threat 

Engagement-Flan is 

entry Access (Engagement-Plan: cut 
Engagement-Plan-Ty re) 

Engagement-Flan 
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Proceed momwtanuel—-Engage-Display (Engagemernt-Flan: 
in out Engagement-Plan-Type, Threat: 
in out Threat-Type}; 

Procedure Auto-Engage-Display (Engagement -Flan: 


in out Engagemant-Plan-Typs, MThreat: 


in out Threat-Type) ; 


j-- 
:3 


Procedure Graphics (Engagement-Plan: : Ole 


Engagement-Plan-Ty pe) 
End Engagement Cisplay 


End Display 
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EFackage Launcher Missile Status Manager is 


Tvpe Status Type i 


la 


Record 
Empty : Boolean 
Masse Tyaee: Sctrsrg cenge A .. C; 
End record 
Task Launcher Missile Status is 
entry Update (Launcher Missile Status in 
tatus Type) 
entry Access (Launcher Missile Status 
out Status Type) 
End Launcher Missile Status 
End Launcher Missile Status Manager 


Type Ship Farameter Type ls 


Record 
Ccurse Weemced=2 range 0 ...5519; 
Speed wepiecdou Lang> 0.2.50; 


Ose -1OGsLas 2) Latactude; 
Pes ctOnetcng: Longizude; 
End record 
Ship Farameter is 
entry Update (Ship Parameter: None 
Parameter Type) 
entry Access (Ship Parameter: cut Ship 
Parameter Type) 
End Ship Paramster 


End Ship Parameter Manager 


V2 





inc 


ackage Environment Manager i 


S 


= 
— 


Type Envirenment Type is 


Record 
Visibility 
Sean otra ce 
Wind Dir 
Wind Spd 
Temperature 
Barometric 


Task Envircrment is 


entry Update (EF 
Type) 

entry Access (E 
Type) 


EmdeENVrcoL ment 
End Environment Manager 
Fackage Threat is 


Manager is 
Type Threat Type is 
Record 

Ship Na me 
Ship Class 
Weapons 

ECM Equip 
Attack Plan 


End record 
Threat is 
entry Update 


Shc Access 
pEteat 
at Manaaer 
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Real Range Q.. 30; 


2 Sincecerpcang> 0..5; 
eee Goo hanger 0... 32579; 
[elias Ger cange 0... 100 ; 
Peiisecgenecangs =100. . 150 
Seen teges range 900..1200 
nvironment: Tie cenv 2s CmmMent 
nviconmant: out Environment 
) Seeing; 
eS tel ng; 
now =n Gs 
ote GE onicie 
2 pore Gs 
reat: in Threat Type 
reat: out Threat Iype) 





Type Track : Boolsan; 

Class Vessel : String; 

Fearing ee ineeger range 0.359; 
Range 2 elmeege. cange (0..500'; 
Ecsition Lat 3: Latitude; 

Eccl enonmel ong 2 Longs tude; 


Course 2. Sineeger sange 0..359; 
Speed [eecdes Sange U2. 50; 
End record 
Task Track is 
entry Add (Track: in Track Type) 
entry Déelste (Track: in Track Type) 
entry Medify (Track: in Track Type) 
elismy meee oo (track: OU Teeack Type) 
End Track 


Type Menu is 
hee ac 
Undetergined at this tine 


End record 


[+3 


ask Menu LCisplay is 
entry Access (Manus out Menu Type} 
End Menu Display 


End Menu Manager 
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Fackage Engagement Plan Manager is 
Type Engagement Plan is 
Track Desig : String; 
Type Plan >: Boolean; 


Num Massiles =: Integer range 0..24; 


Sequence eee nemaly: 
Miss Tyoe oearng. Gange As. C; 
End record 


ie 
Task Engagement Plan is 
entry Access (Engagement Plan: out Engagement 
Plan Type) 
End Engagement Plan 
End Engagement Flan Manager 


é Manager 
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APPENDIX E 
HSCLCS SAMELE SOFTWARE SPECIFICATIONS 


Sample sofiware specifications for HS. CLES 
Sret . i3}j. 
Operationsl Data/tnicrma*ion Requze=nene 
Baselines Design & 
lee Surface Contact Fosition 10 20 (min 
(rance/bearing). 
The use of bearing line in 
addition to the 1b requirement 
reduces the number of displayed 
surface contacts Ly two per 
kearing line. 
-Designated Target X 
Target Categery and Classifi- 
cation Displayed. 
~Unintended Target (s) ne 
Target Category and Classifi- 
Gaeach Displayed. 
ib. Surface Contact/Eearing Line 71 3 (min) 
Peeown Ship Position X 
Sanat COoNnzact Position 1 3 (min) 
faeeoca Party Targeting Data Sources 2 3 (min) 


Designation 


WCIP shall resolve target position 


based on range and bearing input 


from 3rd party or bearing lines 


frem rd parties cr own ship. 


fron 





-Manual Entry of Bearing Lines 


~Manual Entry of Kange and Bearing 


5S. Target Classification 
-Llarge (default) 
berger chan a patrel boat. 
-~Smail 
moescl boat cr smaller. 


pemeccntactys Track Course Direction 
indtcator 
Program automatically compénsates 
EGE Owl ship"’s motion. 
=Yarection Indicatcr 
~Dead Reckoning (Cwn Ship Only) 


fae cCn act/Track Targeting Data Source 
-Manual Input 
With appropriate data source error; 
meeludes 3rd party. 
-~Automatic Input 
=v LES 
cl Ai 
-SONAR 
-EW/ES@ 


-Tarcet Designation Systen 


8. Wind Farameters (relative) 

-~Speed 

=Actual 

Manual input. 

-Default value 
mwarecticn 

-~Actual 

Manual input. 

-Default value 


N27 


Ps 


PS PS OPS OPS 





9. Témperature 
-~Actual 
Manual input. 


-Default values 


10. Precipitation 
-Yes 
Manual input. 
-Ne (default value) 


11. Operator Cues/Lockouts 
-Launch Inhibited (lockouts/scus) 
All launch inhibits excerft roll/ 
Peeecn Cutout. 
-Missile Ready (cué) 
-Data Age (cus) 
Target and envircrmental data. 
-Missile Launch Status (cue) 
=CallyRail Empty (missile away) 
“Missile Dud Declaraticn 
-New Contact/Track to be Input (cue) 
peadedal Acticen (lockout /cue) 


ize fine/sClicck 
-~ZULU Time 
Start clock: AutcRatic entry via 
NIDS Interface and/or manual eéEntry. 
murme on Target 
Manual encry. 
-Time cf Launch 
Computation. 
=Ccuntdcwn 
Includes Time-to-Fir2 and 


Pate—-tc—-Iinpact. 


teeeelLoacout Status/Missile Variant 


Masnwifticaticn 


oo) 





-Baseline/Block I Tactical Missils 
(RGM-@4A) 

-Royal Navy Submarine HAHPOON 
(EGM-84B) 

When reconfigured for surface 
launch. 

-Block IB Tactical Missile 
(RGM-84C) 

sauock ITC Tac zical Missile 
(RGM-E4D) 

-~Supplemental Identification 
{manual entry: info from lcadout 
logbocks of hybrid/neonstandard 
seaker-MGU combinations). 

“Training Al1-Up Rcund (RTM-84A/C/D 
and aANSH) 


14. Missile In-Flight Tracks 


15. Up +0 180 degree Off-Axis Launch 


Coerational Selections 


—— 2 au ee ae QE GD ae oe ee — ae SE Se Eee SS = 


1. Reference System 
-Tru2 Target Bearing/Relativ2 Target 
Range 
Top of display is north. 
-NIDS Grid 
“Geographic (latitude & longitude) 


fee Lanned Missile Flight Path 
Bor-Ware tO ensure that no fligh= 
path may be selected which could 
result in the acguisiticn of own 
ship. 


3. Search Mode Selection 


zg 


WPS 





-On Line Sizing (default) wyManual X 
Overrids 
On Line Sizing shall be automat- 
icaliy selected if RBL or BOL ars 
net selected. 
-Range and Bearing Launch (RBL) ix 
RBL pattern size shall be a 
mumet? On Of total Elight path 
(Tange =raveled tc target). 
-Beearing Only Launch (BOL) X 


4. Selectable Search Pattern Expansion 

(0 - 360 degrees) X 
For RGM-84D missile only, applies 
to REIL mode and Cr-Line-Sizing 
(OLS) which results in an RBL 
search pattern. 

-Normal Center Expansion A 
For RGM-SYUA/BGM-84UB/RGM -84C 
missiles; default for RGM-84D 


missile. 


5. Enable and Destruct Ranges BOL X 
Default values or manual entry 
(ranges not supplied over NTDS 


interface). 


See High Altitude Hold 

RGM-84D only. 

-No Entry; Default x 
The High Altitude Hold default 

range not to interfere with search 
initiaticn and net to exceed 10nn; 
fee. , High Altitude Hold range is 

set tc the minimus of 10nm or range 


to sé€arch initiation. 





7. 


De 


10. 


-~Manual Entry 
The selected High Altitude Hold 
range must bé less than the range 


mMemsearen Initiation. 


Presearch Fly-Out 

-Sea Skim (RGM-84D only) 
Default mode - Presearch Fly-Out is 
set +o sea skim altitude following 
jne High Altisude Hold. 

-Manual Entry 
Presearch Fly-Out at normal HARPOON 
run-in altitude as used in current 
BoCLCS. 


Terminal Attack Mcde (RGM-84D only) 
~Sea Skim (default) 
-Pcp-uc 
Default override ry manual seléc- 
tion of pop-up, "SMALL TARGET" 
designation by NIDS, or when 
"SMAIL TARGET" is entered manually. 


Missile Assignment for Engagement 
Planning 
Manual entry. 


Multi-Missile Engagemen+ cf 
Désignated Target. 
Baseline: Up to 4 missiles from 2 
Single launcher. (Note: Single 
launcker includes TARTAR and 
ASROC). Design Goal: Up to 8 
massiles from 2 CML‘s. 

-Salvo Missiles Against One Target 
For Simultaneous Arrival (STOT 
Salvc). 


orl 





Operator-planned engage ment. 

-Salvo Against Up to Four Targets 
(single airpcint) From One Launcher 
For Simultaneous Arrival (STOT 
Sevic) . 
Same aimpoint and a different RBL 
search €xpansion for ¢ach RGM-84D 
Missile in order to distribute 
saivoed missiles amorg the targeczs 
ied) t£Ozla ticn. 

~Ripple Salvo as per current HSCLCS 
eu) CONnLiguration. 

~Quick Reaction/Preprogrammed STOT 
Salvc. 
Hodtfised HSCLCS automatically will 
Calculate and enter a different 
waypoint for each RGM-84D missile 
in a guick reacticn salvo for 


Simultaneosus time-on-target (STOT). 


11. Backgrcund data and sector data 
request. 
Usable with NIDS interface only. 


PXGAGENENT DISPLAYS 


feeeeecontact/Track Uncertainity Ellipse 
-~Designated Surface Target 
-~Unintended Targets 
If selected by operator. 


2. Predicted Time-on-Target 


BemeecoObcabilizy of Acquisition 
Numerical value. 
-Designazed Targets 


~Unintended Targets 
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If selected by operator. 


uy, Seeker Search Pattern Outline 


For seleczed search mcde. 


5S. Missile Flight Path 


For all selécted missiles. 
6. Booster Drop Zone 


7. Missile Power Application Warning 


— +. ae =. a 


1. Test/Maintenance 
-Missile BIT Results 
-~GO/No~Go Indication 
-Failure Status Cede 
-~HSCLCS BIT Resuits 
-Go/No~-Go Indication 


~Failure Status Ccde 


Zan) Tratning Mode 
Inherent capability provided by 
system design. Design to utilize 
data frcom NTDS and/or external 
training support devices via an RS 
232 serTiai interface. 
mecutact/Irack Location (actual or 
Simulated). 
-CfF Board SourceysNTDS 
-Own Ship SensorsysNTDS 
=Sanual Input 
San Ship Pesition (actual or siaul- 
ated). 
-Training Scenario Parameters 
meEnvaronmental Ccndicions 
~Operaticnal Planning Selactions 


Le, 


rr PF PS ORNS 





3. Data Extract 

Design ~o be compatible with an RS 
232 serial interface to provide for 
data storage/disfiay in off-line 
devices (€.0., tape cassette recor- 
der). 

~Target/Targeting Data 

~Missile Initialization Data 

-BIT Results 


4G. Major Display Features 

-Variatle Range Scale 
NoK=, 32K-, 64K-, 128K-~, 192K-, 97 
266K~yard radius. The 256K-yard is 
the default scale. 

SOLtSet 

-Zoom 
SK-, 16K- or 32K~-yard radius. 

-Special Symbols 

~Cursor, with Bearing/Range readout 
Manually controlled. 
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APPENDIX = 
HSCLCS SYSTEM DIAGRAMS 


These fcur diagrams illustrate the current configuration 


of the HSCLCS and the new proposed ons. 
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Figure F.1 
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Figure F.2 Existing Cannister Launch #SCLCs 
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Propesed Cannister Launch HSCLCS WCIP. 


Figure F.3 
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